|
ENGINEERING FARM KNOWLEDGE FOR A
SEAMLESS DECISION SUPPORT SYSTEM
BY
HARBANS LAL
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
1989
Copyright 1989
by
Harbans Lal
Dedicated to
the Farming Community of the World
ACKNOWLEDGEMENTS
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
pages
ACKNOWLEDGEMENTS...................................... iv
ABSTRACT................................................ viii
CHAPTER
I INTRODUCTION.................................... 1
Justification............................... 1
Objectives................................... 4
II REVIEW OF LITERATURE.......................... 7
Conventional Decision-aid Tools................. 7
Machinery Management Applications............ 9
Limitations.................................. 14
Knowledge Engineering Concepts and Applications 16
Knowledge Classification.................... 17
Knowledge-Based Decision Systems............ 18
Applications.................................. 27
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
pages
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
APPENDICES
I KNOWLEDGE-BASES.... .............................. 192
II MINI-CONFERENCE FOR FARMSYS QUALIFICATION......... 198
REFERENCES..... ......... ............................... 212
BIOGRAPHICAL SKETCH... ................................ 225
vii
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
by
HARBANS LAL
December 1989
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,
viii
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
conventional approaches.
CHAPTER I
INTRODUCTION
Justification
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
2
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
3
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
initiative.
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
4
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.
Objectives
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;
5
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
production systems.
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
6
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.
CHAPTER II
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
8
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
9
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
farm-scale models.
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
10
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
times.
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
11
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,
1984).
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
operations.
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
12
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
13
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 model
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
14
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.
Limitations
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
15
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
operations.
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.
Knowledge Classification
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)
heuristic knowledge.
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)
procedural knowledge.
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
18
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.,
1988).
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
19
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
user.
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
development.
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
20
(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
programs.
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
21
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
approach.
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
22
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
simulation.
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.
23
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.
24
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
development shells.
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
25
simple languages to very elaborate development environments
(Pepper, 1986).
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
applications.
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
26
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,
1988).
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.,
1987).
Applications
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.
28
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).
29
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
insecticide.
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.
30
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
31
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.
32
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).
CHAPTER III
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
INPUT
KNOWLEDGE
EXPERT
PROCEDURAL AN
ANALYSIS
KNOWLEDGE SYSTEM
SYSTEM
SIMULATION
REPORTS
Figure 3.1 Functioning of an integrated decision support
system
35
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.
L
C- N
_. .
x < -4
I'd
U o
rr 04
LL O
-Jo
cz
0 -- -
\2Z -
L a
hr r-
1()
00
cr
o z
z
2-H
37
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
procedural languages.
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
versions.
Object-Oriented Simulation
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
home consumption.
SGOVT. MARKET
CLIMATE POLICIES INFO
INDV. PREF. REGIONAL IRRIGATION FINANCE/
AND GOALS CROPPING FACILITY BANKS
SYSTEMS
AGRONOMI- SELECTED MACHINERY MANAGE-
CAL INPUTS CROPPING AND MENT DE-
SYSTEMS LABOR CISIONS
Figure 3.3
Objects and environment of an operational farm
system with crop production activity.
CROP
PRODUCTION
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
simulation.
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.
farm("DavisFarm","SantaRosa",400,400,
"CropProduction", "dvs")
labor("Laborer_l","Jerry","m",["General"],
"Avail")
tractor("Tractor_l","JD4450",148,["Jerry"],
"Avail")
implement("Implement_2","LandPrep","DiskHarrow",
["Tractor_l","Tractor_2"],4.74,7,"Avail")
crops("Crop_3","Wheat",["Fertilize","Harrowing",
"Plowing","Planting","FertiSpreading",
"Harvesting"])
fieldi("Field 1", fielddl, 20, "SandyLoam",
["Cotton", "Wheat"],["DPL41", "FL302"],
[150, 165], ["Fertilized", "Fertilized"],
"NotIrrigated", "NotNeeded", [750,125],
[1200,110], "Avail")
operations("PlantFertiOps", "Planting", "Soybeans",
136, 182, [[0,3,1],[3,8,0.5]], ["Planter_77"],
0.76)
Figure 3.4 Examples of items of different object-classes
of Davis farm in the format of dynamic databases
of PROLOG.
42
F- -
0 E UJ _
C'-4
0 a: < 0O~ O
f Lu o E D
U 3 F
0 F (0
4~4
4~4
(D 0
c0 0C0
a~ a,
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)
aa
O C,,
W cc
LLI
120 U)
0 0
a: cc c L (-)
Lu ZW
"I I I CO D
Farm Objects and their Attributes
Objects Attributes
Farm Name, Location, Total Area, Cultivated Area,
Principal Activity, Farm Code
Labor
Tractor
Implement
Irrigation
Equipment
Crop
Field
Operations
Number, Name, Sex, Functions, Availability
Model, Hp, Operators List, Availability
Number, Type, Name, Tractors/Operator List,
Width, Speed, Availability
Number, Specification, Capacity, Operators
List, Availability
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,
Availability
Operation Type, Operation Name, Crop, Earliest
Start Time, Latest Finish Time, Work Hours
Conditions List, Implement List, Efficiency
Scheduled
Work Hours Month, Schedules Daily Working Hours
-----------------------------------------------------
Table 3.1
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
cropping intensity.
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
contain "NotNeeded."
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.
46
In addition to the farm objects, the simulator also needs
local weather and evapo-transpiration data and crop irrigation
requirements for scheduling irrigations.
Knowledge Representation
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
47
backup implements for an operation which are generally ignored
in conventional programming models of simulation.
Model Description
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
modifications.
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
chapter.
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
3.6.
GET FARM, WEATHER
YEARSS, SCHEDULED
WORK HOURS
FIND CROPPING SEASON
SELECT FIRST DAY AS
CURRENT DAY
FOR THE CURRENT DAY
MAKE ALL FIELDS, LABOR
AND MACHINERY AVAILABLE
FOR WORK
AND
WORK ON FIELDS) READY
FOR OPERATION
UPDATE CURRENT DAY
BY ONE
CURRENT DAY
)
LAST CROPPING DAY
Yes
PREPARE REPORTS
Figure 3.6
Flow chart of execution of the operations
simulation
No
II
49
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
interval.
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
work.
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.
Figure 3.7--continued
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
Field Operations
No-Work Report for
Irrigation
No-Work Report for
Field Operations
Julian day, month, field, crop,
operation, total area, accumulated
done area, day's work, implement,
tractor, operator, and number of
hours worked.
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
report.
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.
- - - - - - - - - - - - - - - - - - - - - -
Table 3.2.
53
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
different operations.
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
54
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",
doSimulation:-
getFarmKnowledge(labor, field, equipment,
crop,irrigate, operation, tractor,
implement),
getOtherKnowledge(expertfile, weatherfile,
workhrsfile),
findSimulationDuration(SDay,FDay),
simulateSeason(SDay,FDay),
writeResultFiles(resultl,result2,result3,result4).
simulateSeason(SDay,FDay):-
asserta(currentday(Sday)),
repeat,
currentday(SimDay),
makeAvailAll,
simulateADay(Simday,"Irrigation"),
simulateADay(Simday,"HarvestingOps"),
simulateADay(Simday,"PlantProtectionOps"),
simulateADay(Simday,"PlantFertiOps"),
simulateADay(Simday,"LandPrepOps"),
Sdayl=Simday+l,
changeDay(Sdayl),
Sdayl>Fday.
simulateADay(SDay,OpsType):-
fieldc(FieldN,Crop),
chkCondAndWork(FieldN,Crop,Sday,OpsType),
fail.
simulateADay(_,_):-!.
chkCondAndWork(FieldN,Crop,_,_):-
fieldo(FieldN,_,_,,Crop,OpsList,_,
_i_l_i_,_) '
OpsList=[],!.
Figure 3.8 Simplified code of operations simulation in
PROLOG
chkCondAndWork(FieldN,Crop,SDay,OpsType):-
fieldo(FieldN,Tarea,CUarea,Darea,Crop,
OpsList,,_,_,_ _, _),
OpsList=[Opsll_],
type(OpsType,OpsTypeList),
not(member(Opsl,0psTypeList)),
operations(_,Opsl,Crop,_,FtOpera,_,_,),
chkTimeFinish(Sday,FtOpera,AnsT),
adjustParameters(OpsList,Tarea,CUarea,Darea,
AnsT,"No",OpsListl,Tareal,CUareal,Dareal),
recordWork(FieldN,Crop,Tareal,CUareal,Dareal,
OpsListl,"Avail"),!.
chkCondAndWork(FieldN,Crop,SDay,OpsType):-
fieldo(FieldN,Tarea,CUarea,Darea,Crop,
OpsList,_,_ _, ,_,_),
OpsList=[OpslL],
fieldi(FieldN,_,_,_,[Cropl,Crop2],
__I__i__ _/_) ,
Crop=Crop2,
not(Cropl="NoCrop"),
fieldo(FieldN,_,CultArea,_,Cropl,
CurOpsList,_,_,_,_,_,_),
decideWork3(CurOpsList,CultArea,Reason),
recordNoWork(Sday,FieldN,CUarea,Crop,Ops1,
OpsType,Area,Reason,[],"NotChecked",[],"
NotChecked",[],"NotChecked"),
operations(_,Opsl,Crop,_,FtOpera_,,_,_),
chkTimeFinish(Sday,FtOpera,AnsT),
adjustParameters(OpsList,Tarea,CUarea,Darea,
AnsT,"No",OpsListl,Tareal,CUareal,Dareal),
recordWork(FieldN,Crop,Tareal,CUareal,Dareal,
OpsListl,"NotAvail"),!.
ChkCondAndWork(FieldN,Crop,Sday,OpsType):-
fieldo(FieldN,Tarea,CUarea,Darea,Crop,
OpsList,_,_,_,_,_,"NotAvail"),
OpsList=[Opsll_],
recordNoWork(Sday,FieldN,CUarea,Crop,Ops1,
OpsType,Area,"FieldNotAvail",[],
"NotChecked",[],"NotChecked",
[],"NotChecked"),
operations(_,Opsl,Crop,_,FtOpera,_,_,_),
chkTimeFinish(Sday,FtOpera,AnsT),
adjustParameters(OpsList,Tarea,CUarea,Darea,
AnsT,"No",OpsListl,Tareal,CUareal,Dareal),
recordWork(FieldN,Crop,Tareal,CUareal,Dareal,
OpsListl,"NotAvail"),!.
Figure 3.8--continued
chkCondAndWork(FieldN,Crop,SDay,OpsType):-
fieldo(FieldN,Tarea,CUarea,Darea,Crop,
OpsList,_,_,_,_,_,_),
OpsList=[Opsli_],
operations(_,Opsl,Crop,StOpera,FtOpera,
OpsCondList,ImpList,Eff),
chktime(SDay,FieldN,Crop,Opsl,StOpera,
FtOpera,AnsT),
decideWorkl(SDay,FieldN,CUarea,Crop,Opsl,
OpsType,DArea,Ans),
MachinesLAvail(ImpList,Implement,Tractor,
Operator,ImpWidth,Speed,AvailI,TraList,
AvailT,OprList,AvailO)
decideWork2(SDay,FieldN,CUarea,Crop,Opsl,
OpsType,DArea,ImpList,AvailI,TraList,
AvailT,OprList,AvailO),
weather(Sday,Month,_,_,_,Rain),
workHrs(Month,WrkHrs),
calculateHrsIndOps(OpsCondList,Rain,
WorkHrs,WrkHrs),
dayWork=Speed*ImpWidth*Eff*WorkHrs/10.0,
TDarea=Darea+DayWork,
ChangeOpStday(Sday,FieldN,Crop,Opsl),
chkTimeFinish(Sday,FtOpera,AnsT),
chkAreaFinish(CUarea,TDarea,AnsA),
adjustParameters(OpsList,Tarea,CUarea,TDarea,
AnsT,AnsA,OpsListl,Tareal,CUareal,Dareal),
recordWork(FieldN,Crop,Tareal,CUareal,Dareal,
OpsListl,"NotAvail"),
makeMachinesOccp(Tractor,Implement),
makeEntityOccp(labor,Operator),
minR(TDarea,CUarea,DareaR),
maxR(CUarea,DareaR,CUareaR),
writeworkreport(SDay,Month,FieldN,Crop,Ops1,
CUareaR,DareaR,DayWork,Implement,
Operator,Tractor,WorkHrs),!.
chkCondAndWork(_,_,_,_):-!.
Figure 3.8--continued
58
"simulateSeason" and "simulateADay" which work in an
hierarchical order. They can be thought of as subroutines in
procedural languages.
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
59
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
completed.
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
reports.
60
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
types.
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
61
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.
Table 3.3
User-defined PROLOG predicates and their
description, used by different clauses of
"chkCondAndWork" of the Operations Simulator for
scheduling field operations on daily basis.
Predicate Description
field a database predicate to control sequencing of
different fields in the simulation process.
field
field
member
operation
chkTimeFinish
a database predicate containing additional
information about fields not included in the
fielddc.
a database predicate to keep track of actual
status of fields during various stages of
simulation.
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
effect.
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".
Table 3.3--Continued
Predicate Description
chkAreaFinish checks if "Darea" for the current operation
has equaled or exceeded the currently used area
of the field.
recordWork
recordNoWork
decideWork?
machineLAvail
weather
workHrs
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
predicate "adjustParameters".
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
their arguments.
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.
------------------------------------------------------------
Table 3.3--Continued
Predicate Description
changeOpStday changes the earliest start time for harvesting
makeMachines-
Occp
minR
maxR
writeWork-
Report
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.
65
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
day.
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?
66
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
possible.
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
system.
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
67
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
management.
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
inputs.
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
68
29 O O O
0
z
C- ,C
0 0oZ cr co
-- 1- X
S. -- W ]
o o a O ,
D- 0 (D 0 l 0 i 4 >:
O--
w co wI u:
- cc
(0
co W 0 "- : wr
0 0 m Q OZ J
z W C.)
w -J w uj w ( o9 I-I
w CC 0 _^
< 0
Co i- a n
w I- 5
w w w ,
C Co r-- 0
w co W 0o
co Co I- w Co
S2
z I 0: ^-- 0 < Q o)
Co_ z z 7
Sm Z
I II
<0 W0 wC -- <
0 Co o
\ Z
< C3 w i_ -
Sz cc Z co Wo
0 w cc < z < co :5
w C CL 0
QL co 1
LT
69
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
70
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
I
t USER'S SUPPLIED
HEURISTICS
Figure 3.10
Flow chart of functioning and decision
process in the Operations Analysis Report
SCHEDULED Good Start and Good Finish
Actual n Actual
START Start Finish
It
SCHEDULED
FINISH
+
4t
Good Start and Bad Finish
Bad Start and Good Finish
Actual Actual
Start Finish
Start and Bad Finish
Actual
Start
Figure 3.11
Schematic representation of built-in heuristics
for the Operations Analysis report of the Expert
Analysis System
It
Actual
Finish
It
Table 3.4
Rule set for qualifying delays in an operation
based upon its actual start and finish times
within its agronomical work window using the one-
third heuristics.
Conditions Decisions
The operation starts
within first one-third and
finishes before last one-
third of the operational
work window.
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
operational window.
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
where
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
delay
BothOps Both operations (current and last) responsible
for delay
77
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
78
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-
sized implements,
3) Increase operational capacity of self-propelled
implements and
4) Increase operational capacity of perfectly matched
implements.
The system uses the following steps to develop the
recommendations.
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
power unit(s).
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.
Table 3.6a
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
analyzed)
Condition FurtherAction
AvgWrkHrs
AvgWrkHrs>=WrkHrsReco "ImpProb"
Table 3.6b
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 analyzed)
Current Operation Last Operation FurtherAction
AvgWrkHrs
AvgWrkHr>=WrkReco AvgWrkHrs
AvgWrkHr=WrkReco CurOpsWrkHrsLastOpsImp
AvgWrkHr>WrkReco AvgWrkHrs>=WrkReco ImpBoth
Where
AvgWrkHrs- Calculated average work hours for the operation
WrkReco- Recommended work hours for the operation
WrkHrsBoth- Recommend increased work hours for both operations
CurOpsImpLastOpsWrkHrs-
Check implement list for the current operation
and recommend increased work hours for the last
operation
CurOpsWrkHrsLastOpsImp-
Recommend increased work hours for the current
operation and check implement list for the last
operation
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
analyzed
Execution procedure
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
reports.
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
analysis.
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.
83
3) It gets the heuristic from the user to characterize
the delays.
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
built-in heuristics.
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
Month Date
Initially Supplied E-" 0
Operation Consi-
dered Delayed If
Start After
=_068 E-E-1
Latest Finish
Month Date
Finish After-
Finish After
S$WE
OPERATION ANALYSIS REPORT
Figure 3.14 Screen layout for the Operations Analysis report
with the user-supplied heuristics.
========================================
85
object-item, and development and execution process of the
report follow.
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
critical operations.
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
Rule 1
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.
Rule 2
IF Amt of Least Util Item = 0.0
THEN Recommend to withdraw of the Item,
BECAUSE Farm is not using this Item at all.
Rule 3
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.
Rule 4
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.
Amt=Amount Util=Utilized
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.
Table 3.7
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
farm.
Entity Type Knowledge-bases searched
Implements-- -- - -- -- -- - -- -- -
Implements
(All Types)
Tractors
Operations
Implement
Operators Tractors, Implement and
Irrigation Equipment
88
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
object-class.
Rule 5
IF NumCom=0.0,
AND NumUnq = NumTot,
THEN Recommend not to withdraw the Item,
BECAUSE Item is allocated alone everywhere,
AND It has no complimentary unit on farm.
Rule 6
IF NumCom=NumTot,
AND NumUnq = 0.0,
THEN Recommend strongly to withdraw the Item,
BECAUSE Item has a complimentary unit everywhere
it is allocated.
Rule 7
IF NumCom>=0.50*NumTot,
THEN Recommend to withdraw the Item,
BECAUSE More than 50% times the Item has
a complimentary unit.
Rule 8
IF NumCom<0.50*NumTot,
THEN Recommend not to withdraw the Item,
BECAUSE Less than 50% times the Item has
a complimentary unit.
Figure 3.15b
NumTot=
NumUnq=
NumCom=
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
available
|
|
PAGE 1
ENGINEERING FARM KNOWLEDGE FOR A SEAMLESS DECISION SUPPORT SYSTEM BY HARBANS LAL 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 1989
PAGE 2
UNIVERSITY OF FLORIDA llliillil 3 1262 08552 3453
PAGE 3
Copyright 1989 by Harbans Lai
PAGE 4
Dedicated to the Fanning Community of the World
PAGE 5
ACKNOWLEDGEMENTS 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 knowledgebased 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 IV
PAGE 6
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.
PAGE 7
TABLE OF CONTENTS pages ACKNOWLEDGEMENTS iv ABSTRACT viii CHAPTER I INTRODUCTION 1 Justification 1 Ob j ectives 4 II REVIEW OF LITERATURE 7 Conventional Decision-aid Tools 7 Machinery Management Applications 9 Limitations 14 Knowledge Engineering Concepts and Applications 16 Knowledge Classification 17 Knowledge-Based Decision Systems 18 Applications 27 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 VI
PAGE 8
pages 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 14 6 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 APPENDICES I KNOWLEDGE-BASES 192 II MINI -CONFERENCE FOR FARMSYS QUALIFICATION 198 REFERENCES 212 BIOGRAPHICAL SKETCH 225 Vll
PAGE 9
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 by HARBANS LAL December 1989 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. • • « Vlll
PAGE 10
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 expert (s) . 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 ix
PAGE 11
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 conventional approaches.
PAGE 12
CHAPTER I INTRODUCTION Justification 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
PAGE 13
2 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
PAGE 14
3 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 initiative. 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 (Al) 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 Al languages can allow for the modelling of aspects of the system that are typically ignored or are difficult to model when using conventional
PAGE 15
4 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. Objectives 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;
PAGE 16
5 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 production systems. 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
PAGE 17
6 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.
PAGE 18
CHAPTER II 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 operation (s) 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 operation (s) 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 field (s) . 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
PAGE 19
8 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
PAGE 20
9 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 farm-scale models. 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
PAGE 21
10 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 times. 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
PAGE 22
11 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; Lai and Frerie, 1984) . 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 multicrop. 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 processoriented approach for simulating grain and hay harvesting operations. 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
PAGE 23
12 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
PAGE 24
13 was achieved during earlier stage (s) . 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 model 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
PAGE 25
14 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. Limitations 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
PAGE 26
15 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 operations. 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) .
PAGE 27
16 Knowledge Engineering Concepts and Applications Knowledge engineering includes the task of acguiring 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 metaknowledge.
PAGE 28
17 Knowledge Classification 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) heuristic knowledge. 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) procedural knowledge . 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
PAGE 29
18 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., 1988) . 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 ( Intel liCorp, 1988) . Approaches to development The approaches to developing knowledge-based decision systems can be broadly classified as hybrid approach and
PAGE 30
19 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 user. 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 development. 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
PAGE 31
20 (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 programs . 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
PAGE 32
21 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 (refered 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; Lai et al., 1987; Pascoe, 1986) . A specific instance of an object-class (refered to as object-item in this dissertation) is generated when unique values are allocated to different attributes of an objectclass. 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 approach. PROgramming 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
PAGE 33
22 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 simulation. 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.
PAGE 34
23 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.
PAGE 35
24 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 development shells. 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
PAGE 36
25 simple languages to very elaborate development environments (Pepper, 1986) . 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 appl ications . 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 expert (s) 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
PAGE 37
26 routinely needs to be taught to others, 4) the problem is we 11 -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 expert (s) 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, 1988) . 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, userinterface, etc. It is analogous to a procedure used to certify a human expert for his expertise. A knowledge system designed to identify crop insect (s) and to make recommendation on their control should be subjected to the same kind of the qualification tests as an entomologist.
PAGE 38
27 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., 1987) . Appl icat ions 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.
PAGE 39
28 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; Lai 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) .
PAGE 40
29 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 insecticide. 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 Levels 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.
PAGE 41
30 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. 1e 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
PAGE 42
31 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 modelbase 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 modelbase is then activated to locate and assemble models which can satisfy this goal.
PAGE 43
32 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) .
PAGE 44
CHAPTER III 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 refered to as FARMS YS 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 33
PAGE 45
34 INPUT KNOWLEDGE PROCEDURAL KNOWLEDGE SIMULATION REPORTS EXPERT ANALYSIS SYSTEM Figure 3.1 Functioning of an integrated decision support system
PAGE 46
35 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.
PAGE 47
36
PAGE 48
37 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 procedural languages. 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 versions. Object-Oriented Simulation 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 seguence 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.
PAGE 49
38 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 home consumption.
PAGE 50
39 CLIMATE GOVT. POLICIES MARKET INFO INDV. PREF. AND GOALS REGIONAL CROPPING SYSTEMS IRRIGATION FACILITY FINANCE/ BANKS AGRONOMICAL INPUTS SELECTED CROPPING SYSTEMS MACHINERY AND LABOR MANAGEMENT DECISIONS CROP PRODUCTION Figure 3 . 3 Objects and environment of an operational farm system with crop production activity.
PAGE 51
40 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 simulation. 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 objectclasses 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.
PAGE 52
41 farm ( "DavisFarm" , "SantaRosa" , 400 , 400 , "CropProduction" , "dvs" ) labor ( "Laborer_l" , "Jerry" , "m" , [ "General" ] , "Avail") tractor ( "Tractor_l" , "JD4450" , 148 , [ "Jerry" ] , "Avail") implement ( "Implement_2" , "LandPrep" , "DiskHarrow" , [ "Tractor_l" , "Tractor_2" ] , 4 . 74 , 7 , "Avail" ) crops ( "Crop_3" , "Wheat" , [ "Fertilize" , "Harrowing" , "Plowing" , "Planting" , "FertiSpreading" , "Harvesting"] ) fieldi("Field_l", "fieldl", 20, "SandyLoam", ["Cotton", "Wheat"] , ["DPL41", "FL3 02"] , [150, 165], ["Fertilized", "Fertilized"], "Notlrrigated" , "NotNeeded", [750,125], [1200,110], "Avail") operations ("PlantFertiOps", "Planting", "Soybeans", 136, 182, [[0,3,1], [3,8,0.5]] , [ "Planter_77" ] , 0.76) Figure 3.4 Examples of items of different object-classes of Davis farm in the format of dynamic databases of PROLOG.
PAGE 53
42 CO CO < cr HI Q. o o o CO CO UJ ' CL o' °1 _l
PAGE 54
43 Table 3.1 Farm Objects and their Attributes Objects Farm Labor Tractor Implement Irrigation Equipment Crop Field Attributes 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 List, Availability 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, Availability Operation Type, Operation Name, Crop, Earliest Start Time, Latest Finish Time, Work Hours Conditions List, Implement List, Efficiency Month, Schedules Daily Working Hours Operations Scheduled Work Hours
PAGE 55
44 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 cropping intensity. 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 contain "NotNeeded." 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.
PAGE 56
45 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.
PAGE 57
46 In addition to the farm objects, the simulator also needs local weather and evapo-transpiration data and crop irrigation requirements for scheduling irrigations. Knowledge Representation 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
PAGE 58
47 backup implements for an operation which are generally ignored in conventional programming models of simulation. Model Description 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 modifications . 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 chapter . 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 3.6.
PAGE 59
48 GET FARM, WEATHER YEAR(S). SCHEDULED WORK HOURS FIND CROPPING SEASON SELECT FIRST DAY AS CURRENT DAY FOR THE CURRENT DAY MAKE ALL FIELDS, LABOR AND MACHINERY AVAILABLE FOR WORK AND WORK ON FIELD(S) READY FOR OPERATION UPDATE CURRENT DAY BY ONE No CURRENT DAY LAST CROPPING DAY Yes PREPARE REPORTS Figure 3 . 6 Flow chart of execution of the operations simulation
PAGE 60
49 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 interval . 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 work. 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.
PAGE 61
50 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.
PAGE 62
51 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. Figure 3.7 — continued
PAGE 63
52 Table 3.2. Simulation Reports and their Contents Report Description Contents Work Report for Irrigation Work Report for Field Operations Julian day, field name, irrigation applied (mm of water) , irrigation equipment and operator used, day's soil moisture, pending number of irrigations and their amount. Julian day, month, field, crop, operation, total area, accumulated done area, day's work, implement, tractor, operator, and number of hours worked. No-Work Report for Irrigation No-Work Report for Field Operations Summary Report for Field Operations 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 report . Field, crop, operation, scheduled start and finish times, actual start and finish times, number of days and hours worked, total done area, number of non-working days.
PAGE 64
53 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 different operations. 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
PAGE 65
54 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",
PAGE 66
55 doSimulation: getFantiKnowledge (labor, field, equipment, crop, irrigate, operation, tractor, implement) , getOtherKnowledge(expertfile, weatherfile, workhrsf ile) , findSimulationDuration(SDay,FDay) , simulateSeason(SDay,FDay) , writeResultFiles (resultl , result2 , results , result4 ) simulateSeason(SDay,FDay) :asserta(currentday (Sday) ) , repeat, currentday(SimDay) , makeAvailAll , simulateADay (Simday, "Irrigation") , simulateADay (Simday, "HarvestingOps") , simulateADay (Simday, "PlantProtectionOps") , simulateADay (Simday, "PlantFertiOps") , simulateADay (Simday, "LandPrepOps") , Sdayl=Simday+l , changeDay(Sdayl) , Sdayl>Fday. simulateADay (SDay,OpsType) :fieldc(FieldN,Crop) , chkCondAndWork ( FieldN , Crop , Sday , OpsType) , fail. simulateADay (_,_) :-! . ChkCondAndWork (FieldN, Crop, _,_) :fieldo ( FieldN, _,_,_, Crop, OpsList,_, OpsList=[ ] , ! . Figure 3.8 Simplified code of operations simulation in PROLOG
PAGE 67
56 chXCondAndWork{FieldN,Crop,SDay,OpsType) :f ieldo ( FieldN , Tarea , CUarea , Darea , Crop , OpsList, _,_,_, _,_,_) , OpsList=[Opsl |_] , type(OpsType,OpsTypeList) , not (member (Opsl,OpsTypeList) ) , operations (_, Opsl , Crop , _, FtOpera ,_,_,_) , chkTimeFinish(Sday,FtOpera,AnsT) , ad j ustParameters (OpsList , Tarea , CUarea , Darea , AnsT , "No" , OpsListl , Tareal , CUareal , Dareal) , recordWork (FieldN , Crop , Tareal , CUareal , Dareal , OpsListl, "Avail") , ! . chlcCondAndWork (FieldN, Crop, SDay,OpsType) :f ieldo (FieldN , Tarea , CUarea , Darea , Crop , OpsList, _,_,_, _,_,_) , OpsList=[Opsl j_] , fieldi (FieldN, _,_,_, [Cropl,Crop2] , Crop=Crop2 , not(Cropl="NoCrop") , f ieldo ( FieldN, _,CultArea,_,Cropl, CurOpsList, _,_,_, _,_,_) , decideWork3 (CurOpsList, CultArea, Reason) , recordNoWork ( Sday , FieldN , CUarea , Crop , Opsl , OpsType, Area, Reason, [ ] , "NotChecked" , [ ] , " NotChecked" , [ ] , "NotChecked") , operations (_, Opsl , Crop ,_, FtOpera ,_,_,_) / chkTimeFinish (Sday, FtOpera, AnsT) , ad j ustParameters (OpsList , Tarea , CUarea , Darea , AnsT, "No", OpsListl, Tareal, CUareal, Dareal) , recordWork ( FieldN , Crop , Tareal , CUareal , Dareal , OpsListl, "NotAvail") , ! . chkCondAndWork (FieldN, Crop, Sday, OpsType) :f ieldo (FieldN , Tarea , CUarea , Darea , Crop , OpsList, _,_,_,_,_, "NotAvail") , OpsList= [Opsl ] _] , recordNoWork (Sday , FieldN , CUarea , Crop , Opsl , OpsType, Area, "FieldNotAvail" , [ ] , "NotChecked" , [ ] , "NotChecked" , [] , "NotChecked") , operat ions (_, Opsl, Crop, _, FtOpera, _,_,_) , ChkTimeFinish ( Sday , FtOpera , AnsT) , ad j ustParameters ( OpsList , Tarea , CUarea , Darea , AnsT, "No", OpsListl, Tareal, CUareal, Dareal) , recordWork (FieldN , Crop , Tareal , CUareal , Dareal , OpsListl, "NotAvail") , ! . Figure 3.8 — continued
PAGE 68
57 chlcCondAndWork(FieldN,Crop,SDay,OpsType) :f ieldo ( FieldN , Tarea , CUarea , Darea , Crop , OpsList, _,_,_, _,_,_) , OpsList=[Opsl j_] , operations (_, Opsl , Crop , StOpera , FtOpera , OpsCondList,IinpList,Eff ) , chktime ( SDay , FieldN , Crop , Opsl , StOpera , FtOpera, AnsT) , decideWorkl (SDay , FieldN , CUarea , Crop , Opsl , OpsType,DArea,Ans) , MachinesLAvail (ImpList, Implement, Tractor, Operator, ImpWidth, Speed, AvailI,TraList, AvailT , OprList , AvailO) decideWork2 (SDay , FieldN , CUarea , Crop , Opsl , OpsType , DArea , ImpList , Avail I , TraList , AvailT, OprList, AvailO) , weather(Sday, Month, _,_,_, Rain) , workHrs (Month, WrkHrs) , calculateHrsIndOps(OpsCondList,Rain, WorkHrs, WrkHrs) , dayWork=Speed*ImpWidth*Ef f *WorkHrs/10 . , TDarea=Darea+DayWork , ChangeOpStday(Sday, FieldN, Crop, Opsl) , chkTimeFinish(Sday, FtOpera, AnsT) , chkAreaF in ish (CUarea , TDarea , AnsA) , ad j ustParameters (OpsList , Tarea , CUarea , TDarea , AnsT, AnsA, OpsListl, Tareal, CUareal, Dareal) , recordWork (FieldN , Crop , Tareal , CUareal , Dareal , OpsListl, "NotAvail") , makeMachinesOccp (Tractor , Implement) , makeEntityOccp( labor, Operator) , minR (TDarea, CUarea, DareaR) , maxR(CUarea,DareaR,CUareaR) , wr iteworkreport (SDay , Month , FieldN , Crop , Opsl , CUareaR, DareaR, DayWork, Implement, Operator, Tractor, WorkHrs) , ! . chkCondAndWork (_,_,_,_) :-! . Figure 3.8 — continued
PAGE 69
58 "simulateSeason" and "simulateADay" which work in an hierarchical order. They can be thought of as subroutines in procedural languages. 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
PAGE 70
59 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 completed. 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 "fieldc" 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 reports .
PAGE 71
60 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 "fieldc" 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 "fieldc" database have been tried. Having worked on all the entries of the database "fieldc", 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 types . 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
PAGE 72
61 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.
PAGE 73
62 Table 3.3 User-defined PROLOG predicates and their description, used by different clauses of "chkCondAndWork" of the Operations Simulator for scheduling field operations on daily basis. Predicate fieldc fieldo Description 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 "fieldc". field a database predicate to keep track of actual status of fields during various stages of simulation. member operation 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 operationclass are listed in Table 3.1. chkTimeFinish 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 effect. ad justParameter adjusts the values of "OpsList", "Tarea", "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" .
PAGE 74
63 Table 3.3 — Continued Predicate chkAreaFinish recordWork Description recordNoWork decideWork? 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 predicate "adjustParameters". 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 their arguments. 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. calculates the actual working hours (WrkHrs) for the operation based its operating conditions (OpsCondList) , rainfall (Rain) and scheduled work hours (WorkHrs) for the day. machineLAvail weather workHrs calculateHrsIndOps
PAGE 75
64 Table 3.3 — Continued Predicate changeOpStday makeMachinesOccp minR maxR writeWorkReport Description 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.
PAGE 76
65 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 day. 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 Analvsis 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?
PAGE 77
66 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 underutilized 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 possible. 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 system. 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
PAGE 78
67 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 management . 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 inputs . 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
PAGE 79
68
PAGE 80
69 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 guestions such as how many hours "Laborer_l" 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
PAGE 81
70 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 operation (s) 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
PAGE 82
71 INTERNAL REPORT r No GET AN 1 OPERATION FROM THE USER Yes MORE REPORTS ? rii CHARACTERIZE DELAYS No fstop) I BUILT-IN HEURISTICS L DELAYS IN OPERATION 9 Yes I USER'S SUPPLIED HEURISTICS OPERATION(S) TO
PAGE 83
72 SCHEDULED Actual START start Good Start and Good Finish Actual Finish SCHEDULED FINISH Actual Start Good Start and Bad Finish m Actual Finish f Bad Start and Good Finish Bad Start and Bad Finish Figure 3.11 Schematic representation of built-in heuristics for the Operations Analysis report of the Expert Analysis System
PAGE 84
73 Table 3.4 Rule set for qualifying delays in an operation based upon its actual start and finish times within its agronomical work window using the onethird heuristics. Conditions Decisions The operation starts within first one-third and finishes before last onethird of the operational work window. Good Start and Good Finish The operation starts within first one-third and finishes during last one-third time of the operational window. Good Start and Bad Finish The operation starts after first one-third and finishes before last one-third of the operational window. The operation starts after first one-third and finishes during last one-third of the operational window. Bad Start and Good Finish Bad Start and Bad Finish
PAGE 85
74 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. Operation fs) 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
PAGE 86
75 Exeunple Rule l (Entry No. l)
PAGE 87
76 Table 3.5 Induction table for developing rules for identifying the operation (s) to be analyzed for the delays in the current operation. No
PAGE 88
77 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 operation (s) in order to identify their (implements) operational parameters for improving timeliness of the operation. The implement list(s) attached to the operation (s) being analyzed is (are) divided into three sub-lists of different implements types namely self-propelled, perfectly-matched and
PAGE 89
78 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 undersized implements, 3) Increase operational capacity of self-propelled implements and 4) Increase operational capacity of perfectly matched implements. The system uses the following steps to develop the recommendations . 1) It identifies the operation (s) to be analyzed and their problems using the criteria discussed earlier.
PAGE 90
79 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 power unit(s) . 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.
PAGE 91
80 Table 3.6a Induction table for identifying the actual problem (s) with the operation (s) 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 analyzed) Condition FurtherAction AvgWrkHrs=WrkHrsReco "ImpProb" Table 3.6b Induction table for identifying the actual problem (s) with the operation (s) 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 analyzed) Current Operation Last Operation FurtherAction AvgWrkHrs=WrkReco AvgWrkHrs=WrkReco CurOpsWrkHrsLastOpsImp AvgWrkHr>WrkReco AvgWrkHrs>=WrkReco ImpBoth Where AvgWrkHrsCalculated average work hours for the operation WrkRecoRecommended work hours for the operation WrkHrsBothRecommend increased work hours for both operations CurOpsImpLastOpsWrkHrsCheck implement list for the current operation and recommend increased work hours for the last operation CurOpsWrkHrsLastOpsImpRecommend increased work hours for the current operation and check implement list for the last operation WrkHrsProbWork hours problem for the operation being analyzed and recommend increasing them ImpProbProblem with implement used for the operation, check the implement list of the operation being analyzed
PAGE 92
81 Execution procedure 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 reports . 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) Operation (s) 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 analysis. 2) It presents to the user the agronomic work window of the selected combination.
PAGE 93
82 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Expert Advisor-Operations Analysis Report * **************************************************** Press to Select Items of Farm Objects Field ^^^^ Crop ^^^^^^^ Operation ^ OPERATIONS ANALYSIS REPORT Figure 3.13 Screen layout for the Operations Analysis report with the built-in heuristics.
PAGE 94
83 3) It gets the heuristic from the user to characterize the delays. 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 built-in heuristics. 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
PAGE 95
84 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Expert Advisor-Operations Analysis Report * **************************************************** Press to Selectltems of Farm Objects Work Windows Initially Supplied Operation Considered Delayed If Earliest Start Month Date Start After Latest Finish Month Date Finish After SSSWsSk Figure 3.14 Screen layout for the Operations Analysis report with the user-supplied heuristics.
PAGE 96
85 object-item, and development and execution process of the report follow. 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 critical operations. 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
PAGE 97
86 Rule 1 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. Rule 2 IF Amt of Least Util Item =0.0 THEN Recommend to withdraw of the Item, BECAUSE Farm is not using this Item at all. Rule 3 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. Rule 4 IF Amt of Least Util ltem<0. 20*Amt of Most Util Items, AND Amount of Least Utilized Item >0.0, THEN Go for Further Analysis. Amt=Amount Util=Utilized 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.
PAGE 98
87 Table 3.7 Knowledge-bases searched for different objectclasses to find out the number of places the item appears as possible candidate for a job on the farm. Entity Type Knowledge-bases searched Implements (All Types) Tractors Operators Operations Implement Tractors, Implement and Irrigation Equipment
PAGE 99
88 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 object-class.
PAGE 100
89 Rule 5 IF NumCom=0 . , AND NumUnq = NumTot, THEN Recommend not to withdraw the Item, BECAUSE Item is allocated alone everywhere, AND It has no complimentary unit on farm. Rule 6 IF NumCom=NumTot , AND NumUnq = 0.0, THEN Recommend strongly to withdraw the Item, BECAUSE Item has a complimentary unit everywhere it is allocated. Rule 7 IF NumCom>=0 . 50*NumTot , THEN Recommend to withdraw the Item, BECAUSE More than 50% times the Item has a complimentary unit. Rule 8 IF NumCom<0.50*NumTot, THEN Recommend not to withdraw the Item, BECAUSE Less than 50% times the Item has a complimentary unit. Figure 3.15b 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. NumTot= Total number of places the item appears as a possible candidate for a job. NumUnq= Number of places the item appears as a unique candidate for a job. NumCom= 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 available
PAGE 101
90 In the execution of this report, the user is asked to select the object-class such as Tractor, Laborers, or Implements through a pop-up menu. In the case of Implements, he is asked to make second choice for the implement type class such as land preparation, planting, harvesting, etc. On the final selection of the object-class, the system goes through the preparation and presentation of the reports. The system prepares and guards information for all the stages of the report. However, the user is not obliged to go through all of them. He can quit the advisor at any stage he wants to make changes in the farm resource-base. In making these changes, the user can use the recommendation of the expert system or his own experience. Accumulated Work Report This report works as a support to the earlier two reports: Operations Analysis and Machinery Usage reports. The user can utilize it to get additional details to further analyze the recommendations made by these reports and/or to get information about the items not covered by either of them. This report does not make any specific recommendations for the selected combination of object-items of the object-classes. However, its contents facilitate the user making management and planning decisions.
PAGE 102
91 Development and execution process The report is prepared utilizing the work report of the operations simulation. The user selects object-items for different farm object-classes such as crop, field, tractor, implement, etc. and the time interval for the report through pop-up menus on the screen layout presented in Figure 3.16. He can select one or all items from an object-class. On the selection of different object-items, the accumulator separates all the entries from the simulation report for the selected combination of object-items over the desired period. It then adds up the work hours and work days of the separated entries and prepares and presents two reports . The first report, in a concise format, consists of dates of actual start and finish of the usage of the selected object-items, total accumulated work hours, number of days actually worked, average daily work hours, average monthly work hours and list of the months during which the selected items actually worked. The second report, in a detailed format, consists of a complete listing of selected entries from the simulation work report on the daily basis over the desired time period. The concise report is automatically presented on the lower half of the screen (Figure 3.16), however the presentation of the detailed report is optional and the user can by-pass it, if he so desires.
PAGE 103
92 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Expert Advisor-Accumulated Work Report * Press to Select Duration of the Report Start Month Finish Month Write in Date and Press Start Date Finish Date Press to Select Items of Farm Obiects Crop ^^^^^ Field ^^^^^^^ Operation Figure 3.16 Screen layout for the Accumulated Work Report.
PAGE 104
93 Knowledge-Based Yield Estimation The ultimate goal of a farm system with crop production activities is to produce crops, either for the market and/or for home consumption (Figure 3.3). The factors which most influence crop yields can be broadly classified into natural resource factors (soil types, climate, etc.) and management factors (crop varietal selection, irrigation and fertilization levels and timings of critical operations) . Farmers have little control on natural resource factors. However, farm productivity can be greatly improved by appropriate selection of management factors and their timely implementation. Farmers can benefit significantly with timeliness of critical operations in a crop production process. One of the important factors which controls the timeliness of field operations is the machinery and labor availability on the farm. Farmers want to maintain an appropriate size and mix of machinery to complete their operations on time and economically. They neither want to be over-equipped with machinery which increases their fixed costs, nor do they want to be in short supply of equipment which could delay their critical operations and drastically reduce their crop yields and profits. They also want to know how an addition of a particular implement would alter the timeliness of different operations and would influence the crop yields and overall farm production and profits.
PAGE 105
94 A knowledge-based yield estimation system which appraises the farm production of different crops and their gross and net returns has also been developed and integrated with the farm decision system. The yield assessments for different fields are based upon the user supplied management inputs such as crop variety, irrigation and fertilization levels and simulated timings of different operations on an individual field. These yield values for different fields are then converted into the overall farm production and profit based upon the cost of production and expected sale price for different crops. The user can utilize this system, as demonstrated in chapter IV, to assess overall production, net and gross returns from his farm under his current farming system and to study the effect of variation in sale prices of different produce on his overall net returns. In combination with the operations simulation, the yield estimation system can also be utilized to study the effects of various machinery management decisions (daily work hours, machinery size and their working speed) on the timings of different operations and their influence on farm production and profit. The yield estimation system is structured in two components: crop yield knowledge-base (s) and an expert search system. The crop yield knowledge-bases can be developed using the crop growth models, acquiring knowledge from regional crop experts or from any other source available in the region.
PAGE 106
95 The expert search system is a PROLOG program. It collects crop related management input factors from the usersupplied field file and dates of critical operations from the simulation reports for each field and searches through the crop yield knowledge-bases to find the yield levels for the crops grown on different fields. The overall production for a field is then calculated by multiplying the yield times its harvested area. Crop Yield Knowledge-Bases The crop yield knowledge-bases are the relational tables of the input factors (both natural resource and management) and the expected yields for different crops. They are stored in the form of dynamic databases of PROLOG. The general format along with some hypothetical examples of these tables is presented in Appendix I. To demonstrate the functioning of the estimation system, a set of these tables for soybeans, peanut and wheat were developed using IBSNAT crop growth simulation models (IBSNAT, 1987) . A set of input values required as input for the models, and presented in Table 3.8 were selected from their respective databases. These values were chosen to approximately represent the test farm situation. The agronomic work window for planting for each crop was divided into weekly intervals. Simulation runs of the models were then made using the selected values of input factors and
PAGE 107
96 Table 3 . 8 Values of input parameters selected for running crop models for developing hypothetical crop yield knowledge-bases Parameter Value selected Weather year (s) Soil Type Crop Variety Soybean Wheat Peanut Tallahassee (FL) , 1954 (Considered as dry and also used for operations simulation) Milhopper Fine Sand Bragg Condo Florunner middle date for each week within agronomic work window for planting for each crop. These runs were made using batch files specially made for each model. A single line output for each run consisting of input parameters and the crop yield and its components were saved in a separate file for every crop. These output files then served as induction tables for developing the required knowledge-bases in the form of dynamic databases. The cotton yield values, to complete the knowledge-bases for all crops of the test farm, were then estimated on a hypothetical crop yield distribution curve (Figure 3.17). In this distribution a linear decrease in yield was assumed with delayed planting after first two weeks of the agronomic work window.
PAGE 108
97 Expert Search System This system searches through the crop yield knowledge-bases to estimate the crop yields for different fields on the farm. It can be used to get report for a single crop grown on different fields, for a single field (both or any one crop) or for the whole farm with all fields and crops. The screen layout which allows the user select choices about the field (s) and crop(s) through pop-up menus is presented in Figure 3.18. The flow pattern of the functioning of the system is depicted in Figure 3.19. Similar to expert analysis system, it also works in a repetitive mode and the user can utilize it to get reports for different combinations of fields and crops for the selected farm. Table 3.9 presents Table 3.9. Type of reports produced with different combination of selected entities Selection Type of Report Field Crop One Field One Crop One crop grown on the selected field One Field All Crops All crops grown on the selected field All Fields One Crop One crop grown on all farm fields All Fields All Crops All crops grown on all farm fields
PAGE 109
98 0.800 Yield (T/ha) .700 .600 20 21 22 Planting Weeks Figure 3 . 17 Hypothetical yield distribution of cotton crop as affected by its planting weeks.
PAGE 110
99 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Crop Yield and Profit Estimator * **************************************************** Press to Select Items of Farm Objects Figure 3 . 18 Screen layout for presenting Yield Estimation Report
PAGE 111
100
PAGE 112
101 the types of reports produced with different combinations of the selected object-items from the menus. The total production, cost, gross and net returns for a crop produced on a field are estimated using following equations. P = Y * HA (1) GR = P * SP (2) TC = AA * PC (3) NR = GR TC (4) ANR = NR/CA (5) where P = Total Production (Ton) Y = Yield (Tons/ha) HA = Harvested Area (ha) GR = Gross Returns ($) SP = Expected Sale Price ($/Ton) TC = Total Cost ($) AA = Average Area = (HA+CA)/2.0 NR = Net Returns ($) ANR = Average Net Return ($/ha) CA = Cultivated Area PC = Production Cost ($/ha) The average production cost and expected sale price for the crop is supplied by the user. The Average Area (AA) for estimating total production cost accounts for the situations where machinery constraints result in harvested area less than the cultivated area of a field. The report generated by the expert search system contains field name, its cultivated and harvested areas, crop name(s), weather set, yield, production, sale price, cost
PAGE 113
102 price, total sale, total cost, net profit and net profit per unit area for each field and for complete farm. An Intelligent Information Management System Information management deals with control of inflow and outflow of information, while assuring its adequacy and accuracy (Walton, 1967) . A good and intelligent information management acquires great rewards for an enterprise whereas mismanagement of information carries the threat of very high penalties. In large industrial enterprises specialists, referred to as Information Managers, are hired to carry out this task. A software-based information management system for large and complex simulation models can increase their ease of operation and also their credibility as decision-aid tools. It can help to collect knowledge, needed as an input for the model, from the user and let him update it in a friendly and interactive manner. The simulation model, discussed earlier in this chapter, requires a huge amount of farm specific knowledge in a predefined format for its functioning. A conventional procedural program with input data files would require a good amount of planning, organizational skill and typing ability on the part of the user to provide the model with the needed knowledge even for a small farming enterprise. The complexity of the task increases manyfold if one is required to manage
PAGE 114
103 a large enterprise comprising many farms with different types of cropping systems. A software-based information management system was designed and implemented. It is currently structured to collect farm information and works as an intelligent interface between the user and a field operations simulation model. Object-items of an operational farm system can be classified into two categories namely 1) physical object-class and 2) abstract object-class (Table 3.10). The details about each farm object-class are stored in separate files and are discussed later in this chapter. Items of a physical object-class can be numbered from 1 to "n", where "n" is the total number of items of the objectclass available on the farm. The typical examples are tractors, implements and fields. The items of these objectclasses are shared by other farm object-items. For example, Tractor_2 could be shared by five different implements to carry out seven types of operations on ten different fields. Items of an abstract object-class are not numbered. They do not exist physically on the farm. Unlike physical objectitems, they cannot be shared by other farm object-items. A typical example of this object-class is the operations list associated with a crop. This list is specific to a crop and cannot be shared by other crops. The planting operation, as an example, for different crops could have totally different requirements in terms of their timings and implement list.
PAGE 115
104 Table 3.10 Categorization of different farm object-classes Category Object-class Physical objects laborers, tractors, implements, equipments, crops and fields Abstract objects operations In addition, the objects of an operational farm system are inter-dependent on each other (Figure 3.5). For example, an operator is needed to make a tractor operational, and a tractor is needed to make an implement work in the field as explained earlier in this chapter. Therefore, development of a new set or updating information of an existing object-class file would require information from other related files. It could also require adjustments to one or more farm files to make the changes effective. Table 3.11 presents the files required to carry out different actions on various farm object-classes. For instance, the action to "add New Item" or to "modify An Item" in the tractor file would require information from farm and labor files, in addition to tractor file itself. Therefore, all these files should be present and should be accessible to the system in order to carry out these actions. Table 3.12 presents the listing of files affected by different updating options on various farm files. For example, an addition of a new laborer on the farm would not
PAGE 116
105 Table 3.11 List of files needed to carry out different actions on various farm objects files. File
PAGE 117
106 Table 3.
PAGE 118
107 Table 3.12 List of affected files due to various updating options of different farm objects files. File Name Action Performed Affected Files Names farm farm farm farm delete An Item add New Item modify An Item develop New Set all files deleted action not allowed field Action Not Allowed labor
PAGE 119
108 be effective until the changes in tractor, implement and equipment files are made to allocate the new laborer to different tractors and implements. Characteristics The principal characteristics of an Intelligent Information Management System for a farming enterprise with the crop production as principal activity can be listed as follows. 1) It should be able to adopt itself to the size and the complexity of a variety of farm systems from different locations. 2) It should be very friendly and interact with the user through menus requiring him to do a minimum amount of typing. 3) It should be able to store information about many farms to manage them individually whenever required. The information stored should be accessible to other components of the decision support system such as Operations Simulator, Yield Estimator, and Expert Advisor described earlier in the chapter. 4) It should work for developing a completely new farm set, as well as for updating the information about existing farms by modification, addition and deletion of an entry from different object-class files. It should prohibit the user from making duplicate entries of the same object-item.
PAGE 120
109 5) It should carry out various integrity checks such as cultivated area vs. total area, matching implement power requirement to power available from the power source, etc. during development and updating of farm knowledge. 6) It should be able to decide and collect the information needed to complete different types of machinery set such as self-propelled and the implements needing a separate power unit. 7) The same information should not be asked repeatedly. The information once supplied should be presented to the user, whenever it is a possible selection as an input henceforth. 8) It should keep track of the status of different farm files as affected by any change in the related file(s) and should advise the user accordingly. Components and their Functions An information management system with the above characteristics was designed and implemented in Turbo PROLOG and is named as Information Manager. It consists of two components: 1) Information Generator and 2) Information Modifier. Information Generator lets the user develop information for a completely new farm in a predefined logical sequence. The user fills in information on the specially designed forms on the computer screen. Once any information such as tractor make or model is entered, it need not be typed in again, as it will appear on a pop-up menu the next time
PAGE 121
110 when it is a possible selection as an input, thus saving many typing errors. The information collected is then stored in different files. Information Modifier lets the user update information about the existing farms. It permits him to access any farm file in a developed set and make changes such as addition, deletion of an object-item, or modification of one or more of its attributes in its object-class. The general decision tree of the Information Manager is depicted in Figure 3.20 and is discussed briefly hereafter. Information Generator Information Generator lets the user develop information about different farm object-classes of a new farm. It creates separate files for each class with the extension code supplied by the user. The sequence of collecting information for different object-classes is logically structured. The most needed information is collected first. On the successful completion of the general farm file, the name of the new farm with its extension code is registered with a built-in file manager. On the next usage of Information Manager, the name of the new farm shows up in the menu of farms' name to allow the user to update its information, if he so desires. On initiation of Information Manager, the user is given options to select a farm from a pop-up menu which also
PAGE 122
Ill INFO MANAGER NEW FARM I DEVELOP NEW SET I FARM LABOR TRACTOR IMPLEMENT EQUIPMENT CROPS FIELDS OPERATIONS I EXISTING FARM I MODIFY EXISTING SET -[farI^ MACHINERY CROPS FIELDS LABOR TRACTORS IMPLEMENTS IRRI. EQUIPMENT OPERATIONS' LIST ALL ITEMS DELETE AN ITEM ADD AN ITEM MODIFY AN ITEM DEVELOP NEW SET Figure 3.20 Flow chart of functioning of Information Management System
PAGE 123
112 includes "NewFarm" in addition to the already existing farms. The selection of "NewFarm" leads the user to Information Generator where he can develop information about different objects of his farm. The general farm information (name, location, etc) is developed first followed by labor, tractor, implement, irrigation equipment, crop, field and operation. The development process, in general, of a new farm information involves asking the user for the number of items of the object-class he possesses on his farm. The Information Generator then interacts with the user to collect information about each of them. The "operation" is an abstract object-class (Table 3.10) and its development is controlled internally by the system. In developing the operation file, the user is directly presented with the screen to enter its details rather than asking for their total number as in case of physical objectclasses. The development of the operations file is controlled by the crop file which has a list of operations for each crop. The system picks the first crop from the crop file and obtains details about all the operations present in its list. This process is then repeated for all the crops in the crop file. Information Modifier Information Modifier provides five options: list all items, delete an item, add new item, modify an item, and develop new set for updating knowledge about existing farms.
PAGE 124
113 List all items lists all items for the selected objectclass with their attributes on the screen. The user can examine them to decide his further action. Delete an item allows the user to withdraw one objectitem from its class at a time. In order to withdraw more items, the action should be repeated that many times. The user selects the object-item to delete from the menu of the object-class. Add new item allows the user to add one more item to its existing object-class file at a time. The process involves counting number of object-items in the class, allocating an identification number for the new item and receiving and saving its details. Modify an item allows the user to change one or more attributes of an item an object-class. The process involves letting the user make selection of the object-item, presenting him old attributes of the selected item, letting him make modifications and saving the item with the new attributes. Develop a new set allows the user to develop an entirely new set for any farm object-class. The process involves letting the user select the object-class, receiving number of items of the selected class, then collecting and saving information about each item of the object-class. On selecting one of an already existing farm, the user is led into Information Modifier where he is presented with a menu of different object-classes (farm, machinery, crop.
PAGE 125
114 field and operations) to let him select one to update information. The machinery is further subdivided into labor, tractor, implement and irrigation equipment. On selecting the object-class from this menu, the user is presented with updating options menu (Table 3.11, Figure 3.19). In updating existing information, the Information Modifier first verifies the status of the files needed to carry out the desired action (Table 3.11). In case of nonexistence of any of these files, it advises the user to develop them prior to carrying out the desired action. At this stage, the user is also informed of the effects of his action on other farm files (Table 3.12) and is warned that his updates would not be effective if he does not make changes in other affected files. It then brings the necessary files to memory, initializes screen layout, lets the user select a object-class and its item he would like to update, presents him the old information, if needed, then allows him to make changes in the selected object-item. Finally, it writes the file with updated information to the disk. Knowledge-Bases Utilized and Generated The knowledge manipulated by Information Manager can be broadly classified into a) knowledge utilized and b) knowledge generated by the user.
PAGE 126
115 The knowledge utilized consists of 1) type file, 2) screen layout files, 3) month details file, 4) manager file, and 5) expert file. The farm knowledge generated is stored in different files: 1) farm file, 2) labor file, 3) tractor file, 4) implement file, 5) irrigation equipment file, 6) crop file, 7) field file and 8) operation file. Appendix I presents a simplified version of these files for the Davis Farm located in Santa Rosa County of northwest Florida. This farm has been used as a test farm for operational evaluation and verification of the integrated decision support system. Knowledge utilized The general format of different databases utilized by Information Manager is presented in Table 3.13 and discussed briefly below. T ype file . This file consists of entries of a single database called "type." The database consists of two elements: 1) object-class name and 2) a list of object-items associated with the class. The list associated with certain object-classes can be modified by the user interactively. The typical example is crop and its varietal list. Appendix I gives the complete listing of this file for the test farm. This knowledge-base is utilized to prepare menus to let the user select object-items specific to his farm. The user
PAGE 127
116 Table 3.13 Format of PROLOG knowledge-bases of different files utilized by Information Management System to let the user generate farm knowledge File Name type file month file screen files manager expert Knowledge-bases and their format type (LandPrep Imp, [ "MBPlow" , "AddNewItem" , "DeleteAnltem"]) month ( "January" ,1,31) field ( "name" , str , 8,28,29) txtfield(8,12,12,"Name of Farm") windowsize(20,77) f ilesmanager ( "FarmName" , "FarmCode" , "Exist" , "Exist" , "Exist" , "Exist" , "Exist" , "Exist" , "Exist" , "NotExist" ) et( "October ",2.55) file cropirr("Peanuts","ClayLoam",10,200) soilchar("FineSand", 200. 0,120. 0,140.0) opcond ( "Soybean" , "LandPrep" ,[[0.0,3.0,1.0], [3.0,8.0,0.5]]) opstypedetail ( "LandPrepOps" ,8.0,7.5,7.0,0.76)
PAGE 128
117 can select a single item or a list of items depending upon the type of object-class. The selection for a variety of a crop to be grown on any field is a typical example of single object-item selection from a given list. On the other hand, selecting a list of tractors for an implement is a typical example of selecting a list from an existing list. An example of this database, presented in Table 3.13, signifies that Information Manager currently knows only "MBPlow" as a land preparation type implement. However it can be changed by selecting "AddNewItem" or "DeleteAnltem" from the pop-up menu. Screen layout files . These files are utilized for creating screen layouts for collecting information about different farm object-classes. There is a separate file for each class and is saved as "********. scr, " where the first word represents the name of the class such as farm, tractor, implement, etc. These files consist of entries of three databases and have been adapted from screen handler program of Turbo PROLOG ToolBox (Borland, 1987). Figures 3.21-3.28 present the screen layouts generated by these files. Appendix I gives the complete listing for collecting general farm information. Month file. This file contains entries of a single database with 3 elements namely month name, start Julian day
PAGE 129
118 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-General Farm Information * **************************************************** Action Being Performed Farm Name Location Total Area (ha) Cultivated Area (ha) Press to Select Activity Farm Generally Known As (3-Letters Only) Figure 3.21 Screen layout for collecting general farm information * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Laborers Information * **************************************************** Action Being Performed Farm Name ^^^^^^^^^^^^ Location Total Number of Farm Laborers Supplying Information about ?-r"»»r"»iocooocC'»;-o-*-?c-?o Name (One Word Only, such as JoeSmith) Principal Function (Type in for your own information) Figure 3.22 Screen layout for collecting farm laborers information
PAGE 130
119 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Tractors Information * **************************************************** Action Being Performed Farm Name Total Number of Tractors on the Farm Supplying Information about Make and Model ^^^^^^^ Horse Power (HP)^P (One Word Only, such as JohnDeer3340) Press to Select Operator's List and "End" to Finish the List Figure 3.23 Screen layout for collecting farm tractors information * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Implements Information * **************************************************** Action Being Performed Farm Name Total Numbers Press to Select General Classification Press to Select Specific Implement Name Press to Select Power Unit (sj[ and '| End'] to Finish the List Please Type in the Values and to Make^^Checks Work Speed (Km/hr) ^^^^ Working Width (m) Figure 3.24 Screen layout for collecting farm implements information
PAGE 131
120 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Irrigation Equipment * ********************************************ie******* Action Being Performed Farm Name Total Number of Irrigation Equipment Supplying Information about Make and Model ^^^^^^^M Capacity (ha-cm/hr): (One Word Only, such as CenterPivot40) Press to Select Operator's List and "End" to Finish the List ^^^^ Figure 3.25 Screen layout for collecting irrigation equipment information * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Crops Information * **************************************************** Farm Name ^^^^^^^^^ Total Crop Numbers Supplyin£_Inforaati^^^^^ Press to Select a about Crop PresstoSelectOperations and "End" to Finish Land Preparation Operations Plant and Ferti Application Operations Plant Protection Operations Harvesting Operations ^^'z'z'z'z-z-z'Z'Z'zVz'^'z^'i'z'^z'z%i'z^-Zri'^^ Figure 3.26 Screen layout for collecting farm crops information
PAGE 132
121 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Fields Information * **************************************************** Farm Name ^^^^^^Cult. Area (ha )^^No. of Fields ^^ Supply ing_Info .F4.*lA.4..N.^J?i?.... .?'A®A.4...^.^.®^...(?>.? ) about PresstoSelect PresstoSelect Soil Type Irrigation Type Irri. Equipment Supply Crop(s) Related Information 1. Pressto Select PresstoSelect Crop Variety Days FertilizProduSale Name Name to ation ction Price Mature TYpe^Cost($/ha) ($/TonO 2.: Figure 3.27 Screen layout for collecting farm fields information
PAGE 133
122 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Field Operations Information * **************************************************** Action Being Performed Farm Name Supplying Info about an Operation for Crop Operation Type Operation Name EarliestStartTime j^Press Supply Date and to Select Month) Press LatestFinishTime to Select Month) L?.?.®?.?."^.?J}.^.f-?.-^ Supply Date and Press W^ PresstoSelect ImplementList and "End" to Finish Figure 3.28 Screen layout for collecting field operations information
PAGE 134
123 and last Julian day. This database is utilized to check the validity of date entered by the user for any month as well as to convert Julian day to calendar month and date and vice versa . A typical format of this database in Table 3.13 signifies that the first and the last Julian day for the month of January are 1 and 31 respectively. Manager file . This file consists of entries of a single database named "fileManager. " It has only one entry to start with. The other entries are automatically added on after the successful completion of the development of the general farm file of the new farms. It keeps track of the status ("Exist"/"NotExist") of different files of the farms available to the system. This database consists of 10 elements: farm name, farm code and status of eight object-class files (farm, labor, etc.). This file is used to prepare the menu of farm names for letting the user select a farm with which he wants to work. Expert Knowledge File . This file contains expert knowledge which can be acquired either from the regional experts and/or from the published literature. It stores entries for five databases namely "cropirr", "soilchar", "opcond", "et" and "opstypedetail. " The "cropirr" contains information about the irrigation requirement for various crops when grown on different soil
PAGE 135
124 types. It consists of four elements: crop name, soil type, the amount and number of irrigations that could be applied during the crop cycle. The database "soilchar" contains soil moisture characteristics of different soil types with four elements: soil type, maximum water holding capacity, wilting point, and the threshold limit to start irrigation. The database "et" of two elements stores daily average evapo-transpiration values for different months of the year. The "opscond" database stores knowledge for developing rules to estimate daily working hours for different operations. This database consists of three elements: crop name, operation type and a set of lists of real numbers which is used to estimate actual working hours for the day. Figure 3.29 presents an example of using this database for developing the rule set for actual work hours based upon the rainfall and scheduled work hours for the day. The "opstypedetail" database consists of five elements to provide operational details for different operation types. These elements are operation type and its upper allowable limits for the recommended daily work hours, draft requirement and the speed of operation. This knowledge is used to conduct various types of consistency checks on the information supplied by the user.
PAGE 136
125 General format opcond ( Crop , SoilType , OpsType , ListOfListOfRealNumbers) Specific exeunple opcond ( "Soybean" , "Sand" , "LandPrep" , [[R1,R2,1.0] , [R2,R3,0.5]] Rulel IF rainfall > Rl mm for the day AND rainfall <= R2 mm for the day THEN do 100% of scheduled work hrs Rule_2 IF rainfall > R2 mm AND rainfall <= R3 nan AND schedule Work Hrs for the day are >4 . Hrs THEN do 50% of scheduled work hrs Rule_3 IF rainfall > R2 mm AND rainfall <= R3 mm AND Scheduled work Hrs <=4 . Hrs THEN do 100% of scheduled work hrs Rule_4 IF rainfall > R3 mm THEN don't do any work Figure 3.29 Rules for deciding actual work hours for the day based upon the operating conditions (ListOfListOfRealNumbers) of an operation type (OpsType) , rainfall and scheduled work hours for the day.
PAGE 137
126 For example. Information Manager identifies the inappropriate parameters for an implement in relation to its power sources. In case, the power requirement for an implement exceeds the power available from the smallest tractor selected for the implement, the user is prompted and advised to reduce either the speed or the working width of the implement. Knowledge developed by the user The knowledge developed by the user through Information Manager is stored in eight files of dynamic databases. The attributes of different farm object-classes and their typical format, as stored in the form of dynamic databases were discussed earlier in this chapter (Table 3.1 and Figure. 3.4) . The number of entries for the physical object-class files equals their numbers present on the farm. A brief description of the mechanism of developing information about different farm object-classes follows. Farm file . Most of the user supplied information on this screen is entered except for the principal activity which is selected from a pop-up menu. A built-in checker prevents the user to enter a cultivated area more than the total farm area. The updating options "add Mew Item" and "develop New Set" are not permitted on this file. However, the user can change cultivated area and/or total area using "modify An Item" option.
PAGE 138
127 Labor file . Most of the information is user entered. This file is utilized to generate the list of operators on the farm for allocating them to different farm implements, equipment and tractors. Tractor file . The make, model and horse power of the tractor are entered. The operators list is selected from a pop-up menu consisting of the laborers available on the farm. All updating options are permitted on this file. The user can modify the make, model, horse power and/or operators list associated with the tractor. This file is utilized to generate the list of tractors on the farm for allocating them to different implements. Implement file . The implement type, its name, and tractor/ operator list are selected from the pop up menus, and working speed and width are entered by the user. The pop-up menu of the implement names can be changed interactively by the user. The menu of tractors available on the farm also includes "NotNeeded" option which can be selected for the self-propelled and the manually operated implements. When "NotNeeded" is selected, the user is presented with another menu of laborers available on the farm, and then asked to select the operators list for the implement. All updating options are permitted on this file. The user can change operational parameters (working speed and working width) of the implements and the tractor/ operator list associated with it.
PAGE 139
128 This file is used to prepare the menu of implements to let the user select them (implements) for different operations while developing the operations database. Irrigation equipment file. The equipment specifications such as model and its capacity are entered by the user, and operators list is selected from a pop-up menu consisting of laborers available on the farm. The "NotNeeded" option is also available for the equipment requiring very nominal amount or no labor at all for its operation. All updating options are permitted on this file. The user can change the capacity and the operators list for the equipment. Crop file . Most of the information is collected by selecting object-items from the pop-up menus. The content of the crop menu for selecting crop(s) for the farm can be modified by the user to suit his specific requirements. The information for different operation types is collected separately and then joined together in a proper sequence to form an aggregate list for the crop. The user can select the sequence of operations of each type from the pop-up menus. He can even modify the content of the menus of the land preparation and the plant protection types of operations to include operations suiting to his farming practices for different crops and soil types. All updating options are permitted on this file. The user can change the sequence and content of the list of
PAGE 140
129 operations. This file is utilized to prepare a menu of crops for letting the user to select them for allocating to different fields. Field file . Most of the information is collected through the pop-up menus. The menu for selecting crops for the field also provides the option of "NoCrop" in case the user decides to grow only one or no crop at all on any field. Information Manager keeps track of the unaccounted cultivated area of the farm and prohibits the user from creating fields with total area more than the cultivated area of the farm. All updating options are permitted on this file. The user can change the crop and its characteristics, field area and its irrigation status. Operations file . Number of entries in this file equals the sum total of the items in lists of operations associated with different crops in the crop file. The agronomic work windows (earliest start time and latest finish time) and implement list are collected through pop-up menus. The user can and should select one or more implements for each operation in order to successfully simulate the operation as discussed earlier in this chapter. The updating options of "add New Item" and "delete an Item" are not allowed on this file. However, the user can modify agronomic work windows and the list of implements associated with an operation.
PAGE 141
CHAPTER IV TESTING AND EVALUATION The model testing and evaluation, in general, can be divided into verification and validation. Verification is a process by which programming logic is compared with the programmer's intentions. On the other hand validation deals with comparing the simulation results with the actual system's behavior. For knowledge-based systems, validation has been termed as "qualification." The integrated decision support system, named FARMSYS, combine the four components: Operations Simulator, Expert Analysis, Yield Estimation and Information Management Systems discussed in Chapter III. Testing and evaluation of FARMSYS has been carried out in two stages referred as professional qualification and operational verification. The prof essional qualification involved letting a team of peers evaluate and critique the competence of the system in terms of its knowledge, logic, functioning, user-interface, etc. in order to identify its strengths and weaknesses. The operational verification was aimed to demonstrate the functioning of FARMSYS on a real farm data and also to show how it can be utilized as a planning tool for machinery and labor for multicrop production systems. FARMSYS is operated using a pulldown menu of Turbo PROLOG Toolbox (Borland, 1987) . The 130
PAGE 142
131 schematic representation of the screen layout and the set of menus along with their final actions is depicted in Figure 4.1. On the selection of an option from the main menu (for example "Information Manager") , an executable file and other related information to that option are loaded to the computer memory. The user can then carry out the intended actions. When terminating the job the command is passed back to FARMSYS and the user can select the next option or can select "Quit" to return to DOS. This structure of FARMSYS has made it possible to manage more than 1200 K of executable files under the DOS environment with less than 640 K available memory. The time required to operate different components of FARMSYS depends upon the farm size and type of computer utilized. The system required approximately 45 minutes for one simulation run for the test farm (Davis farm) for two consecutive years on 12 Mhz IBM AT 80286 with 6 Mhz math coprocessor. The actions by other components such as Information Manager and Expert Analysis System are quick and interactive with little time delays. Professional Qualification For the professional level qualification a one-day miniconference on Knowledge-based Decision Systems using Logic Programming was organized at the Department of Agricultural Engineering of the University of Florida. It was attended by
PAGE 143
132 q: o co m I o o CO I CO Q. O
PAGE 144
133 10 experts from U.S. and two from other countries (Appendix II) , in addition to the local faculty members. The structure, components and logic of FARMSYS were presented to the participants in detail. The participants witnessed a demonstration of FARMSYS with a real farm example. The eight professionals specially invited for the qualification session were then asked to evaluate FARMSYS and its different components using a specially designed questionnaire (Appendix II) which contained statements concerning various features of FARMSYS. They had 5 options to select for each option ranging from "strongly agree" to "strongly disagree." They were also encouraged to identify FARMSYS weaknesses and strengths in comparison to other similar tools. The analysis of the questionnaire was carried out in two stages: structured response analysis and non-structured response analysis. In structured response analysis, the answers to different statements were analyzed by grouping and counting the similar responses. Tables 4.1 to 4.8 present these results. The actual comments made by the experts were grouped into four sub-headings: strengths, weaknesses, suggestions and concerns about FARMSYS as non-structured responses.
PAGE 145
134 Table 4.1 Responses to the questionnaire about qualification of the Information Management System of FARMSYS Responses
PAGE 146
135 Table 4.2 Responses to the questions about qualification of Operations Simulation System (Knowledge-bases) of FARMSYS Responses
PAGE 147
136 Table 4.3 Responses to the questions about qualification of Operations Simulation System (Simulation Methodology) of FARMSYS Responses
PAGE 148
137 Table 4.4 Responses to the cjuestions about qualification of Yield Estimation System of FARMSYS Responses
PAGE 149
138 Table 4.5 Responses to the questions about qualification of Expert Analysis System (Machinery Usage Report) of FARMS YS Responses Statements/ Quest ions' 12 3 Strongly agree 3 10 Agree 4 3 4 Undecided 111 Disagree 3 3 Strongly disagree No response Total 8 8 8 ". The numbers correspond to the following statements 1. The objective of the report is sufficiently strong and impressive and users will make intensive use of this report. 2. The criteria utilized for identifying the least utilized item are adequate and realistic. 3. The criteria utilized for deciding recommendation about least utilized item are adequate and realistic.
PAGE 150
139 Table 4.6 Responses to the questions about qualification of Expert Analysis System (Operations Analysis Report) of FARMS YS Responses
PAGE 151
140 Table 4.7 Responses to the questions about qualification of Expert Analysis System (Accumulated Work Report) of FARMS YS Responses
PAGE 152
141 Table 4.8 Responses to the questions about overall qualification of FARMSYS Responses
PAGE 153
142 Structured Response Analysis The analysis of the questionnaire suggested that all participants appreciated the general structure of FARMSYS and approach taken for its development. They had concern about the relevance of the some of the heuristics utilized in different components of FARMSYS for their global applicability. In general, all participants found the Information Management System qualified for receiving farm information in an interactive and friendly manner (Table 4.1). This was considered one of the strength of FARMSYS. There was some concern about the structuring and contents of different components of farm knowledge-bases (Table 4.2 and 4.3). However, mostly all participants found the contents of the reports produced by the simulation essential and adequately structured. They generally agreed that the facility of representing input knowledge using semantic nets has been able to capture the farm knowledge in a more realistic manner than conventional simulators and it has also made FARMSYS a versatile and flexible tool. However, they remained undecided or expressed their disagreement on the claim that FARMSYS checks conditions during simulation more rigorously than conventional simulators. The screen layout for letting the user select field (s) and crop(s), and the structure and contents of the reports
PAGE 154
143 produced by the Yield Estimation System received favorable rating (Table 4.4). However, they were undecided or had disagreement on its qualification to predict the farm yield. The three mini-expert systems (Machinery Usage, Operations Analysis and Accumulated Work Reports) of the Expert Analysis System were considered as important components of FARMSYS (Tables 4.5-4.7) . In general, they were considered qualified for their intended functions. However, some experts had concern about the applicability of built-in heuristics in these reports, specially the 20% criteria of Machinery Usage Report and the one-third rule for deciding "late" starts and finishes in the Operations Analysis Report. These comments led to further revisions in these reports which allow the user to specify the rules for late starts and finishes individually for each operation. Table 4.8 presents the overall evaluation of FARMSYS and its different components. This table indicates that 50% of the participants considered FARMSYS qualified as a decisionaid tool and another 25% were undecided. The Operations Simulator and the Information Management System are its (FARMSYS) strong components. The table also indicates that 50% of the participants were undecided about the qualification of the Expert Analysis System. It was mainly because of the built-in heuristics for characterizing delays in the operations for the Operation Analysis report and the 20% criteria for the Machinery Usage report.
PAGE 155
144 Insufficient time for a thorough presentation of FARMSYS and its different components at the one-day meeting probably accounts for some of the negative responses. However, some of these limitations have been already eliminated in the second version of the Operations Analysis report as discussed in Chapter III. The possible ways to implement some others are discussed in the plans for future work in the next chapter . Non-Structured Responses The non-structured responses mainly dealt with identifying strengths, weaknesses, suggestions and concerns about various components of FARMSYS. Some of the strengths of FARMSYS, identified by the experts (Appendix II) , are its comprehensive nature in machinery selection process for working in a field, its framework and structured approach, its ease of setting up and the flexibility of the produced reports. All these strengths can be mainly credited to the object-oriented and logic programming approach taken in its development. The experts also made some suggestions for improvements which are listed in Appendix II. These suggestions included incorporation of location specific rules for various reports, detailed economics for various operations, the possibility of
PAGE 156
145 including custom hiring of tractors and other machinery at peak periods and a facility to put more than one machine in the same field for the same operation. Role of Mini-Conference in Evaluating Knowledge-based Systems There is a general concern about the methodology for validating or qualifying knowledge-based systems. There are no standard procedures available for this purpose. Different authors (Khuri et al., 1988; Nguyen et al., 1987) have tried different approaches for validating or qualifying knowledge systems. The experiences with FARMSYS indicate that the methodology of a small group of experts meeting together to evaluate and critique the system offers a good and practical alternative for validation. However, it is recommended that such a meeting should occur as two half-day sessions instead of one full day as in the case of FARMSYS. The first half-day session, preferably during an afternoon should be devoted to explaining and demonstrating the system. During the latter part of the afternoon or that evening, the participants should be encouraged to use the system. The second half-day session, preferably during the morning hours of the next day, should be devoted to the experts filling out questionnaires or other related material regarding the qualification of the system.
PAGE 157
146 Operational Level Verification For the operational level verification, contacts were established with three fanners from north Florida through the regional extension agents. Visits were made to their farms and the knowledge about one of them (Davis Farm) was collected using the Information Management System. The Davis farm knowledge (Appendix I) was then utilized as an input to FARMSYS to test its functionality as a decision-aid tool. Additional input knowledge for operating FARMSYS was collected from either the published literature or was based upon estimates of experienced agricultural engineers. The actual weather data of Tallahassee, FL, for the years 1954 (Dry Year) , 1960 (Normal Year) and 1964 (Wet Year) were selected to make the test runs. The test runs are not intended to analyze any particular problem associated with the Davis farm. They are rather intended to show that FARMSYS actually performs as designed, how its different components can be utilized in an integrated form and types of problems it can address for a typical farm setting. Different components of FARMSYS work independently and can be utilized in any sequence the user desires. However, the test runs presented in this chapter were made utilizing different components of FARMSYS as depicted in Figure 4.2.
PAGE 158
147
PAGE 159
148 Description of the Test Farm The test farm consists of about 400 hectares of cultivated area allocated to 23 fields. It has 4 laborers, 5 tractors and 25 implements. It grows 4 crops (cotton, peanuts, soybeans and wheat) and has 10 types of cropping systems as listed in Table 4.9 followed on different fields. Each of these crops and cropping systems require a different number of operations, ranging from 6 for wheat to 16 for cotton, during their production cycles. Each operation has its specific requirements in terms of its agronomic work window and implement list. Each implement has its specific characteristics in terms of tractor or labor requirements and its working width and speed of operation. Setting up Farm Knowledge for Simulation Runs All the crops, except wheat, are planted and harvested during the same calendar year. Wheat is planted in the second half of a year and harvested early in the following year. This requires the program to run for two consecutive years in order to a simulate the complete cropping season of the farm. It also requires two years of weather input which were selected "Dry" after "Dry" year. The crops of the second year were suffixed by character "2" and the agronomic work windows of different operations for the second year were adjusted by adding 365 to their values of the first year.
PAGE 160
149 Table 4.9 Cultivated area and cropping systems of different fields on the Davis farm. Field Area (ha) Cropping System Field_l Field_2 Field_3 Field_4 Field_5 Field_6 Field_7 Field_8 Field_8 Field_9 Field 10 102.2
PAGE 161
150 It is possible to simulate the test farm with its 23 fields. However, for the sake of simplicity of reporting the results, the test runs reported in this chapter were made by grouping all the fields with same cropping system into one single field. This led to a total of 10 fields (Table 4.9) with the total cultivated area of the farm unchanged. The scheduled work hours is another factor which can be adjusted prior to the start of each simulation. It is done using the screen layout depicted in Figure 4.3. The initial test runs were made with six hours of daily scheduled work for all months of the year. This resulted in zero "done area" for many operations on different fields. Then eight hours of scheduled work per day for the entire year also resulted in unfinished work for certain operations. Finally, it was possible to complete all operations on all fields within their operational windows utilizing the daily scheduled work hours as presented in Table 4.10. These initial runs of simulation with FARMSYS showed that the Operations Simulation functioned properly, and they also showed the typical variation in requirements of work hours during different times of the cropping season. The results from the last run, referred as a "success run," are discussed in detail.
PAGE 162
151 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Operations Simulator-Scheduled Work Hours * ****************************ie*********************** Selected Year of Simulation Month WorkHrs/Day Month January ^^^^^^ February March ^^^^^^ April September ^^^^^^ October ^^^^^^ December November WorkHrs/Day Figure 4.3 Screen layout for scheduling working hours for the Operations Simulation.
PAGE 163
152 Table 4.10 Scheduled work hours for different months for simulating field operations on Davis farm Month Scheduled Work Hours January 8 February 8 March 8 April 12 May 12 June 12 July 8 August 8 September 12 October 8 November 8 December 8
PAGE 164
153 Operations Simulation Reports The simulator produces three reports on field operations namely work report, no-work report and summary report. The examples of work and no-work reports for the success run produced by the simulator are presented in Figure 4.4. These examples indicate that on Julian day 100, the simulator tried to carry out five tasks on different fields. It successfully completed three of them and failed to carry out the other two. The tasks successfully completed (Work report) were 1) Plowing 14.2272 hectares on "Field_l" for "Cotton" with total cultivated area of 102.2 hectares using "BottomPlow, " "Tractor_l" and "Jerry" by working 12 hours; 2) Harrowing 30.26 hectares on "Field_2" for "Cotton" using "Disk Harrow," "Tractor_l" and "Keith" by working 12 hours and 3) Fertilize 27.907 hectares on "Field_4" for "Cotton" using "FeriSpreaderLP," "Tractor_4" and "Joe" by working 12 hours. The tasks to Fertilize on "Field_5" and "Field_8" of "Soybeans" were tried but could not be done because the machinery needed was not available ("MachinesNotAvail") . It required "FertiSpreaderLP" which was not available ("NotAvail") . It was being utilized for applying fertilization on "Field_4." The complete summary report of the success run is presented in Table 4.11. The table presents the scheduled work window (ScSt to ScFn) , actual work window (AcSt to AcFn) ,
PAGE 165
154 WorK Report General format workreport( julianDay, Month, Field, Crop, Operation, CultArea, Day's DoneArea, TotDoneArea, Implement, Operator, Tractor, ActWorkHr) For the Julian Day 100 workreport(100, "April", "Fieldl", "Cotton", "Plowing", 102.2, 14.2272, 14.2272, "BottomPlow" , "Jerry" , "Tractor_l" , 12 ) workreport(100, "April", "Field_2", "Cotton", "Harrowing", 76.8, 30.26016, 30.26016, "DiskHarrow", "Keith", "Tractor_2", 12) workreport(100, "April", "Field_4", "Cotton", "Fertilize", 41.6, 27.9072, 27.9072, "FertiSpreaderLP", "Joe", "Tractor_4" , 12) No Work Report General format noworkreport( julianDay, Month, Field, DoneArea, Crop, Operation, DoneArea, ReasonOfNoWork, ImplementList, AvailStatus, WhereAboutlmplementList, TractorList, AvailStatus, WhereAboutTractorList, OperatorList, AvailStatus, whereAboutOperatorList) For the Julian Day 100 noworkreport(100, "April", "Field_5", 79.6, "Soybeans", "Fertilize", 0, "MachinesNotAvail" , [ "FertiSpreaderLP" ] , "NotAvail" , [["FertiSpreaderLP", "field4", "Cotton", "Fertilize"]] , ["Tractor_4", "Tractor_5"] , "Avail", [], [ "Keith" , "Ray" , "Joe" , "Jerry" ] , "Avail" , [ ] ) noworkreport(100, "April", "Field_8", 11.8, "Soybeans", "Fertilize", 0, "MachinesNotAvail" , ["FertiSpreaderLP"] , "NotAvail", [ ["FertiSpreaderLP", "field4", "Cotton", "Fertilize"] ] , [ "Tractor_4" , "Tractor_5" ] , "Avail" , [ ] , [ "Keith" , "Ray" , "Joe" , "Jerry" ] , "Avail" , [ ] ) Figure 4 . 4 Examples of work and no-work reports of the Operations Simulation of FARMSYS.
PAGE 166
155 Table 4.11 Summary report of the "success run" of the Operations Simulation for Davis farm (Appendix I) for the years "Dry" followed by "Dry" (1954) . ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_l (102.2 ha), First Year (Cotton) Fertilize 92 136 92 95 4 48.0 102.2 Harrowing 92 136 96 99 4 48.0 102.2 Plowing 92 151 100 108 8 90.0 102.2 1 Planting 106 161 109 112 4 48.0 102.2 Sprayingl 106 167 113 114 2 24.0 102.2 Cultivationl 116 172 116 120 5 60.0 102.2 Spraying2 122 182 122 123 2 18.0 102.2 Cultivation2 126 189 126 130 5 60.0 102.2 Spraying3 131 212 131 131 1 12.0 102.2 Cultivation3 167 212 167 172 6 60.0 102.2 FertiSpreading 167 212 173 181 5 60.0 102.2 4 Spraying4 167 223 182 183 2 20.0 102.2 Spraying5 172 243 184 184 1 8.0 102.2 Spraying6 183 244 186 186 1 8.0 102.2 1 Harvesting 259 350 262 275 13 152.0 102.2 1 Mowing 289 381 289 294 6 48.0 102.2 Field_l (102.2 ha), Second Year (Cotton) Fertilize 458 502 458 461 4 48.0 102.2 Harrowing 458 502 462 465 4 48.0 102.2 Plowing 458 507 466 474 8 90.0 102.2 1 Planting 472 533 475 478 4 48.0 102.2 Sprayingl 473 533 479 480 2 18.0 102.2 Cultivationl 473 538 481 485 5 60.0 102.2 Spraying2 477 548 486 487 2 24.0 102.2 Cultivation2 492 553 492 496 5 60.0 102.2 Spraying3 497 578 498 499 2 18.0 102.2 1 Cultivation3 533 578 533 537 5 54.0 102.2 FertiSpreading 533 580 538 546 5 60.0 102.2 4 Spraying4 533 578 547 547 1 12.0 102.2 Spraying5 538 609 548 548 1 8.0 102.2 Spraying6 548 610 549 549 1 8.0 102.2 Harvesting 625 716 628 642 14 156.0 102.2 1 Mowing 655 730 655 660 6 48.0 102.2 ScStEarliest Start Time ScFnLatest Finish Time AcStActual Start Time AcFnActual Finish Time WrkDysNo. of Days Worked WrkHrs-No.of Hours Worked WArea -Worked Area NoWrkDys-No. of No-Work Days R-Rain, M-Machinery
PAGE 167
156 Table 4 . 11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_2 (76.8 ha). First Year (Cotton) Fertilize 92 136 96 98 3 36.0 76.8 Harrowing 92 136 100 102 3 36.0 76.8 Plowing 92 151 110 118 6 72.0 76.8 Planting 106 161 121 124 4 42.0 76.8 Sprayingl 106 167 125 126 2 24.0 76.8 Cultivationl 116 172 127 130 4 48.0 76.8 Spraying2 122 182 131 133 2 18.0 76.8 1 Cultivation2 126 189 134 137 4 48.0 76.8 Spraying3 131 212 138 138 1 12.0 76.8 Cultivation3 167 212 173 180 4 48.0 76.8 4 FertiSpreading 167 212 182 187 5 44.0 76.8 1 Spraying4 167 223 188 189 2 16.0 76.8 Spraying5 172 243 190 191 2 12.0 76.8 Spraying6 183 244 192 192 1 8.0 76.8 Harvesting 259 350 276 291 15 120.0 76.8 1 Mowing 289 381 295 299 5 40.0 76.8 Field_2 (76.8 ha). Second Year (Wheat) Fertilize 289 350 299 305 5 40.0 76.8 2 Harrowing 289 350 306 310 5 36.0 76.8 Plowing 289 350 311 316 6 48.0 76.8 Planting 320 366 320 325 6 44.0 76.8 FertiSpreading 396 425 396 401 6 48.0 76.8 Harvesting 502 528 490 499 4 42.0 76.8 1 Field_3 (6 ha) , First Year (Cotton) Fertilize 92 136 99 99 1 12.0 6.0 Harrowing 92 136 104 104 1 12.0 6.0 1 Plowing 92 151 119 119 1 12.0 6.0 Planting 106 161 125 125 1 12.0 6.0 Sprayingl 106 167 134 134 1 12.0 6.0 Cultivationl 116 172 135 135 1 12.0 6.0 Spraying2 122 182 136 136 1 12.0 6.0 Cultivation2 126 189 137 137 1 12.0 6.0 Spraying3 131 212 138 138 1 12.0 6.0 Cultivation3 167 212 181 181 1 12.0 6.0 FertiSpreading 167 212 188 188 1 8.0 6.0 Spraying4 167 223 190 190 1 4.0 6.0 GO Spraying5 172 243 193 193 1 8.0 6.0 Spraying6 183 244 194 194 1 8.0 6.0 Harvesting 259 350 292 293 2 16.0 6.0 Mowing 289 381 300 300 1 8.0 6.0
PAGE 168
157 Table 4.11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_3 (6 ha) , Second Year (Soybeans2) Fertilize 458 502 462 462 1 12.0 6.0 Harrowing 458 502 466 466 1 12.0 6.0 Bedding 472 502 472 472 1 12.0 6.0 Planting 502 548 502 502 1 12.0 6.0 Cultivationl 502 563 503 503 1 12.0 6.0 Cultivation2 520 578 520 520 1 12.0 6.0 Cultivation3 549 589 549 549 1 8.0 6.0 Sprayingl 563 594 563 563 1 8.0 6.0 Spraying2 580 640 580 580 1 8.0 6.0 Harvesting 650 681 637 637 1 12.0 6.0 Field_4 (41.6 ha). First Year (Cotton) Fertilize 92 136 100 101 2 24.0 41.6 Harrowing 92 136 105 106 2 18.0 41.6 Plowing 92 151 120 124 3 36.0 41.6 Planting 106 161 131 138 3 30.0 41.6 1 Sprayingl 106 167 140 140 1 12.0 41.6 1 Cultivationl 116 172 141 142 2 24.0 41.6 Spraying2 122 182 143 143 1 12.0 41.6 Cultivation2 126 189 144 145 2 24.0 41.6 Spraying3 131 212 146 146 1 12.0 41.6 Cultivation3 167 212 182 184 3 28.0 41.6 FertiSpreading 167 212 189 192 4 28.0 41.6 Spraying4 167 223 193 193 1 8.0 41.6 Spraying5 172 243 195 195 1 8.0 41.6 Spraying6 183 244 196 196 1 8.0 41.6 Harvesting 259 350 294 303 8 64.0 41.6 2 Mowing 289 381 304 306 3 24.0 41.6 Field_4 (41.6 ha), Second Year (Peanut2 ) Fertilize 427 456 427 429 3 24.0 41.6 Harrowing 427 456 430 432 3 20.0 41.6 Plowing 427 456 433 437 5 40.0 41.6 Planting 472 487 472 473 2 24.0 41.6 Cultivationl 488 504 488 490 3 30.0 41.6 Sprayingl 488 502 491 491 1 12.0 41.6 Cultivation2 512 563 512 515 2 24.0 41.6 2 Spraying2 533 563 533 534 2 18.0 41.6 Spraying3 540 578 547 547 1 12.0 41.6 Spraying4 549 594 549 549 1 8.0 41.6 Spraying5 562 609 562 562 1 8.0 41.6 Harvesting 611 640 613 621 9 96.0 41.6
PAGE 169
158 Table 4 . 11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_5 (79.6 ha). First Year (Soybeans) Fertilize 92 136 102 105 3 36.0 79.6 1 1 Harrowing 92 136 107 110 3 36.0 79.6 Bedding 106 136 111 116 3 36.0 79.6 Planting 136 182 140 147 4 48.0 79.6 1 Cultivationl 145 197 150 153 4 48.0 79.6 2 Cultivation2 166 212 166 170 5 48.0 79.6 Cultivations 183 228 186 191 6 44.0 79.6 1 2 Sprayingl 197 228 197 197 1 8.0 79.6 Spraying2 214 274 214 214 1 8.0 79.6 Harvesting 284 315 282 287 6 48.0 79.6 Field_5 (79.6 ha). Second Year (Cotton2) Fertilize 458 502 463 465 3 36.0 79.6 Harrowing 458 502 467 470 3 36.0 79.6 1 Plowing 458 507 475 482 6 72.0 79.6 Planting 472 533 486 498 4 42.0 79.6 1 Sprayingl 473 533 500 501 2 24.0 79.6 Cultivationl 473 538 502 506 4 48.0 79.6 1 Spraying2 477 548 507 508 2 24.0 79.6 Cultivation2 492 553 509 512 4 48.0 79.6 Spraying3 497 578 515 516 2 24.0 79.6 2 Cultivations 533 578 538 545 4 48.0 79.6 4 FertiSpreading 533 580 547 552 5 44.0 79.6 1 Spraying4 533 578 553 553 1 8.0 79.6 Spraying5 538 609 554 554 1 8.0 79.6 Spraying6 548 610 555 556 2 12.0 79.6 Harvesting 625 716 648 662 15 120.0 79.6 Mowing 655 730 663 669 5 40.0 79.6 2 Field_6 (16.4 ha). First Year (Peanut) Fertilize 61 90 61 61 1 8.0 16.4 Harrowing 61 90 62 62 1 8.0 16.4 Plowing 61 90 63 64 2 16.0 16.4 Planting 106 121 106 107 2 18.0 16.4 Cultivationl 106 135 108 108 1 12.0 16.4 Sprayingl 106 131 109 109 1 12.0 16.4 Cultivation2 151 197 151 151 1 12.0 16.4 Spraying2 167 197 171 171 1 12.0 16.4 Sprayings 172 212 172 172 1 12.0 16.4 Spraying4 183 223 184 184 1 8.0 16.4 Spraying5 192 243 192 192 1 8.0 16.4 Harvesting 245 274 247 250 4 42.0 16.4
PAGE 170
159 Table 4.11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_6 (16.4 ha), Second Year (wheat) Fertilize 289 350 289 289 1 8.0 16.4 Harrowing 289 350 311 311 1 8.0 16.4 Plowing 289 350 317 318 2 16.0 16.4 Planting 320 366 326 327 2 12.0 16.4 FertiSpreading 396 425 402 403 2 16.0 16.4 Harvesting 502 528 500 500 1 12.0 16.4 Field_7 (10 ha;
PAGE 171
160 Table 4 . 11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_8 (11.8 ha), First Year (Soybeans) Fertilize 92 136 106 106 1 6.0 11.8 10 Harrowing 92 136 117 117 1 12.0 11.8 Bedding 106 136 118 118 1 12.0 11.8 Planting 136 182 154 154 1 12.0 11.8 Cultivationl 145 197 155 155 1 12.0 11.8 Cultivation2 166 212 166 166 1 12.0 11.8 Cultivation3 183 228 192 192 1 8.0 11.8 2 Sprayingl 197 228 198 198 1 8.0 11.8 Spraying2 214 274 215 215 1 8.0 11.8 Harvesting 284 315 289 289 1 8.0 11.8 Field_9 (8 ha) , Second Year (Soybeans) Fertilize 458 502 467 467 1 12.0 8.0 Harrowing 458 502 473 473 1 12.0 8.0 Bedding 472 502 474 474 1 12.0 8.0 Planting 502 548 507 507 1 12.0 8.0 Cultivationl 502 563 508 508 1 12.0 8.0 Cultivation2 520 578 520 520 1 12.0 8.0 Cultivations 549 589 551 551 1 8.0 8.0 10 Sprayingl 563 594 565 565 1 8.0 8.0 10 Spraying2 580 640 581 581 1 8.0 8.0 Harvesting 650 681 642 642 1 8.0 8.0 Field_10 (26.4 ha), Second Year (Cotton) Fertilize 458 502 469 469 1 12.0 26.4 1 Harrowing 458 502 475 475 1 12.0 26.4 Plowing 458 507 484 485 2 24.0 26.4 Planting 472 533 500 501 2 24.0 26.4 Sprayingl 473 533 517 517 1 12.0 26.4 Cultivationl 473 538 518 519 2 24.0 26.4 Spraying2 477 548 521 521 1 12.0 26.4 Cultivation2 492 553 522 523 2 24.0 26.4 Spraying3 497 578 524 524 1 12.0 26.4 Cultivations 533 578 547 548 2 20.0 26.4 FertiSpreading 533 580 554 556 3 20.0 26.4 Spraying4 533 578 560 560 1 8.0 26.4 Spraying5 538 609 561 561 1 8.0 26.4 Spraying6 548 610 567 567 1 8.0 26.4 1 Harvesting 625 716 665 671 5 40.0 26.4 2 Mowing 655 730 672 674 3 20.0 26.4
PAGE 172
161 total hours, days and worked area (Wrk Dys, Wrk Hrs and WArea) for each operation. In addition, the number of no-work days (NoWrkDys) due to rain (R) and due to non-availability of the machinery (M) are also shown in the table. The table indicates that the simulator was able to successfully complete its task for the entire cropping season which covered the period of day 61 (March 1 of the first year) to day 730 (December 31 of the Second Year) . All the operations for different crops were successfully completed on all the fields within their agronomic work windows. They were carried out in proper sequence, as planned. However, some of the later spraying operations (Spraying4, Sprayings, Spraying6) in cotton fields were carried out one after another with no time gaps between them. This occurred because they were planned to be carried out one after another, and the machinery and labor needed to carry them out were freely available with no other operations specified between the two sprayings. However, it can be avoided, if needed, by attaching some additional attributes to the operation object-class, by breaking up one big field into small fields and/or by defining the agronomic windows for subsequent sprayings with some time gaps between them. Expert Analysis System The reports produced by the simulation and discussed above do not provide any indication about the percentage
PAGE 173
162 utilization of different machinery and laborers working on the farm, and/or the relative timeliness of different operations. This task is performed by the Expert Analysis System. It studies these reports in the context of the resource-base available on the farm. The following sections demonstrate the functioning of the three components of the Expert Analyzer and how the information generated by them can be utilized by the user to improve his farming operation. The three components are Machinery Usage, Operations Analysis and Accumulated Work reports. Machinery usage report This report identifies the least and the most utilized items of different farm objectclasses, prepares their seasonal and monthly utilization and makes recommendations to keep them or to withdraw them from the farm, based upon their utilization level and their importance to the current farming operations, as discussed in chapter III. During the initial test runs the Machinery Usage Report identified "GeneralPlanter, " "PDSprayer" and "PDSprayer2" as not being used at all for any operation and recommended their withdrawal. They were withdrawn with no effect on the scheduling of different operations. On the Davis farm, they were probably older machines kept as backup. Table 4 . 12 presents a summary of the Machinery Usage Reports of the test run after withdrawal of the implements not
PAGE 174
163 Table 4.12 Summary of reports and recommendations by Machinery Usage Report of Expert Result Analysis System for the "success run" for Davis farm knowledge. Object Utilization Recommendation and Class Item Hrs Days Reasoning Operator Jerry 2820 286 Withdraw Ray. He has Ray 142 16 a complementary unit(s) Tractor Tractor_3 1432 131 Withdraw Tractor_5. Tractor_5 120 13 It has complementary unit(s) . Implement LandPrep Bottom Plow 476 44 Sub Soiler 64 6 Plant/ Ferti
PAGE 175
164 used at all and identified during initial runs. Table 4.13 presents their monthly usage for the first year of success run of the simulation. The laborer "Ray" is the least utilized laborer on the farm. He works less than 20% of the work hours of "Jerry" (the most utilized laborer on the farm) . In addition, he (Ray) has one or more complementary operator (s) that could carry out the tasks that were assigned to him. So the recommendation was made to withdraw him from the farm work force. In actual practice on the Davis farm, he mostly performs other non-crop operations. The usage reports on usage of tractors and plant protection implements also produced similar recommendations for ••Tractor_5" and "PCultivator" based upon their utilization level in comparison to the most utilized items ("Tractor_3" for tractors and "Sprayer" for plant protection implements) of their respective object-class. The recommendations about Sub-Soiler, Grain Drill and General Grain Combine are different. Although their utilization was less than 20% of the maximum utilized item of their object-class, still the recommendations were not to withdraw them from the farm as they do not have complementary unit(s) to carry out tasks currently assigned to them. The recommendations made by Machinery Usage Report to withdraw any object-item should be implemented with a little caution because of the following reasons. However, the user
PAGE 176
165 Table 4.13 Monthly variation of most and least utilized items of different object-classes on Davis farm during first year of simulation of the "success run . " Item Jan Monthly Utilization (Hrs) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jerry Ray Tractor_3 Tractor 5 BottomPlow SubSoiler Planter_77 Grain Drill Sprayer PCulti -vator^ Cotton Picker General Grain Combine Operators 44 336 228 144 116 16 216 224 100 6 12 36 60 ' 8 Tractors 174 312 180 68 12 36 52 Land Preparation Implements 28 198 12 Plant and Ferti Implements 90 120 12 Plant Protection Implements 42 120 60 68 Harvesting Implements 64 56 56 168 184 00 0000000 ^. Used during the second year only. 56
PAGE 177
166 can take help from other components of the Expert Analysis System (Accumulated Work and Operations Analysis reports) and advantage of his own farming experiences in making final decisions for the withdrawal as demonstrated further in this chapter. 1) The recommendation for withdrawal of an object-item is based upon one-season simulation and do not account for the changes in cropping systems and other factors over time. 2) The recommendations only state that there are one or more complementary units to substitute the object-item to be withdrawn. It does not guarantee that these complementary unit(s) would definitely be available for work when called upon to carry out the tasks currently performed by the objectitem recommended for withdrawal. 3) The item being recommended for withdrawal, though used rarely, may be an important backup resource on the farm and cannot be afforded for withdrawal. Accumulated work report This report provides the user with an aggregate and daily work reports for any combination of object-items of farm entities over a desired interval of time. To further analyze the recommendations of the Machinery Usage Report about "Ray," "Tractor_5" and "PCultivator" this report is utilized to produce their aggregate and daily work reports for the entire cropping season (January 1 of the first year to December 31
PAGE 178
167 Table 4.14 Daily utilization report of Mr. Ray, the least worked laborer on Davis Farm Day Field Crop Operation Implement Tractor 106
PAGE 179
168 Table 4.15 Daily utilization report of Tractor_5, the least utilized tractor on Davis Farm Day Field Crop Operation Implement Operator 151
PAGE 180
169 of the second year). Tables 4.14, 4.15 and 4.16 present these reports in a concise form respectively for "Ray," "Tractor_5" and "PCultivator." The aggregate work hours for different farm object-items being analyzed produced by this report (Tables 4.14-4.16) exactly matched the hours produced by the Machinery Usage report. It shows that the two reports are working correctly. In addition, the tables present some supplementary information which can be utilized to further analyze the recommendations of the Machinery Usage Report. It seems that "Ray" and "Tractor_5" have some things in common which should be considered in deciding their withdrawal from the farm. Both of them are used mainly for lighter operations such as fertilizer spreading and are used together for most of the time. For example, "Ray" operated "Tractor_5" for 10 out of 13 total working days during the cropping season. It seems "Tractor_5" makes a good match with "Ray" for lighter operations such as fertilizer spreading and spraying. The withdrawal of either of them could lead to engaging heavier tractors and/or operators, which might not be economically viable and could lead to delays in other operations. However, the Davis farm has another tractor ("Tractor_4") of similar specifications which might be able to fill in its gaps at no extra cost. To further analyze the recommendations, the user can and should also consult the Operations Analysis Report to receive
PAGE 181
170 its advice about various operations carried out by the objectitems being considered for withdrawal. Operation analysis report This report analyzes different operations for their timely start and timely completion. It identifies factors for their delays and makes recommendations to overcome them in a cost effective manner. The two versions of this report, as stated earlier, have been developed. They respectively work with a built-in (one-third rule) and user-supplied heuristics for qualifying delays in operations and subsequently finding their remedies. Table 4.17 summarizes the recommendations of the Operations Analyzer with the built-in heuristics for the operations employing "Tractor_5, •• "Ray" and/or "PCultivator. " This table shows that the operations performed employing these object-items either did not have a timeliness problem or their problems were not directly related with the object-items recommended for withdrawal. In most cases, the advice was to increase work hours or speed for the operations prior to ones engaging these object-items. To verify the functioning of the second version of the Operations Analysis Report, the operation of "Cotton" planting on "Field_3" was selected for the analysis by it. This operation has scheduled work window between Julian days 106 to 161 (corresponding to April 14 to June 8) and operation
PAGE 182
171 Table 4.17 Recommendation of Operations Analyzer for the operations carried out by "Tractor_5", "Ray" and/or "PCultivator" Field Crop Operation Prob" Recommendation Field
PAGE 183
172 completed in one day on the 125^'' Julian day (corresponding to May 3rd) . With the critical window between May 5 and May 25, the analyzer was able to identify the timely start and timely completion of the operation. However, when the critical window was changed to April 20 to May 25, the analyzer identified the delayed start and timely completion of the operation and recommended to increase the working width of the planter ("Planter_77") used for the planting operation. The scheduled work hours and speed of operation for "Planter_77" were at their upper limits and there was no possibility of increasing them. Considering the recommendations of the different components of the Expert Analysis System, additional test runs were made to study the validity of these recommendations and demonstrate the functioning of FARMSYS as a decision-aid tool. The results of each run are described briefly below. Test Runs with FARMSYS Run 0. This run was made by withdrawing "Chisel Plow," "General Planter" and "PDSprayer" from the farm using the Information Management System and with no changes in work schedule. It produced exactly the same simulation reports (Table 4.11) as the success run. However, the Machinery usage report indicated that there were two more implements namely
PAGE 184
173 "NoTillPlanter" and "PDSprayer2 , " which were not being utilized at all. Run 1 . This run was made by withdrawing "NoTillPlanter" and "PDSprayer2" in addition to "Chisel Plow," "General Planter" and "PDSprayer," and it also resulted in the same simulation report. However at this stage, the Machinery Usage Report indicated that there were no more object-items (machinery and labor) which were not being utilized at all. The earlier discussion about the recommendations of various reports of Results Analyzer was based upon this run. Run 2 . This run was made by withdrawing "Ray" from the farm with no other change in the work schedule or implement parameters. The simulation run was successfully completed with all operations being completed within their agronomic work window. However, there were slight shifts in the actual start and completion of certain operations which initially involved "Ray." Most of these were spraying operations on different fields (Table 4.18) which were delayed by a day or two. This happened because "Keith," the substituting operator, was busy elsewhere and was not available to start the operations on days carried out during earlier simulation. To study the affect of withdrawal of "Ray" on the performance of "Tractor_5," the Accumulated Work Report was used to produce its daily utilization report (Table 4.19). Although, the types of operations carried out by "Tractor_5" during the two simulations were similar, there were some
PAGE 185
173
PAGE 186
175 Table 4.18 — Continued Operation S . Window SSt SFn Case 1 ASt AFn Case 2 ASt AFn Case 3 ASt AFn Field_6 (16.4 ha), Second Year (Wheat) Fertilize 289 350 289 289 290 290 290 290 Field_7 (10.0 ha), First Year (Peanut) Cultivation2 151 197 151 151 151 151 Spraying4 183 223 186 186 186 186 Spraying5 192 243 194 194 196 196 Field_7 (10.0 ha). Second Year (Cotton) FertiSpreading 533 580 553 553 554 554 Spraying4 533 578 557 557 558 558 Spraying5 538 609 558 558 559 559 Sprayinge 548 610 559 559 560 560 Field_8 (11.8 ha), First Year (Soybeans) Fertilize 092 136 106 106 109 109 Harrowing 092 136 117 117 117 117 Bedding 106 136 118 118 118 118 Sprayingl 197 228 198 198 202 202 547 548 548 552 152 152 184 184 193 193 556 556 559 559 560 560 561 561 117 117 118 118 119 119 208 208 547 548 554
PAGE 187
176 Table 4.19 Daily utilization report of "Tractor_5", the least utilized tractor on Davis farm after withdrawal of "Ray" Day
PAGE 188
177 changes in actual operations performed by it ("Tractor_5") in the two cases. It was also interesting to note that the overall utilization of "Tractor_5" decreased from 120 hours in 13 days to 108 hours in 11 days with the withdrawal of "Ray" from the farm. And "Keith," another laborer on the farm, became its operator for all eleven days. The reduction in work hours of "Tractor_5" may mainly be attributed to the non-availability of an operator to operate "Tractor_5" all the days it became a possible choice for work. Run 3 . This run was made by withdrawing "Tractor_5" in addition to "Ray" with no other change. The simulation was successful in completing all the operations within their agronomic work windows. There were some additional shifts in the start and/or completion of spraying operations (Table 4.18). However, it was interesting to note that some operations such as "Spraying4" and "Sprayings" on "Field_6" got expedited with the combined withdrawal of "Ray" and "Tractor_5." This may primarily be attributed to the priorities of different items of different object-classes (implement, tractor and operator) used to carry out various tasks. At this stage, "Tractor_2" became the least utilized tractor on the farm (Table 4.20). However, it was not recommended to be withdrawn from the farm because it was utilized more than 20% of the most utilized tractor ("Tractor_4") . However, the recommendation for withdrawal of "PCultivator" remained unchanged.
PAGE 189
178 Table 4.20 Effect of withdrawal of the least utilized items of different farm object-classes the recommendations of Machinery Use Report Run and Specification Ob j ectItem Usage (Hrs) Recommendation 1. With Jerry "Ray" , Ray "Tractor_5", Tractor_3 "PCultiTractor_5 vator" & Sprayer "MCultiPCultivator vator" 2. Without "Ray" 3. Without "Ray" and "Tractor 5" 4 . Without "Ray" , "Tractor" , and "PCultivator" Jerry Keith Tractor_3 Tractor_5 Sprayer PCultivator Jerry Keith Tractor_4 Tractor_2 Sprayer PCultivator Jerry Keith Tractor_4 Tractor_2 Sprayer MCultivator 2820 142 1432 120 552 24 2844 734 1428 108 560 24 2924 654 1492 516 560 24 2912 654 1480 516 560 72 Withdraw "Ray" Withdraw "Tractor_5" Withdraw "PCultivator" Do not withdraw "Keith" Withdraw "Tractor_5" Withdraw "PCultivator" Do not withdraw "Keith" Do not withdraw "Tractor_2" Withdraw "PCultivator" Do not withdraw "Keith" Do not withdraw "Tractor_2" Withdraw "MCultivator" 5. Without Jerry 2896 "Ray", Keith 630 "Tractor_5", Tractor_3 1468 "PCultiTractor_2 516 vator" & Sprayer 560 "MCultiSprayCoupe 280 vator" Do not withdraw "Keith" Do not withdraw "Tractor_2" Do not withdraw "SprayCoupe"
PAGE 190
179 Run 4 . This run was made by withdrawing "PCultivator. •• All the operations were successfully completed within their agronomic work windows with some additional shifts in start and/or completions times of the different operations. However, at this time, the Machinery Usage Report identified "MCultivator" as the least utilized plant protection implement (Table 4.20) and recommended its withdrawal from because it was also utilized less than 20% of the most utilized item (Sprayer) of the same object-class. Run 5 . This run was made by additionally withdrawing "MCultivator." The simulation completed all the operations within their agronomic work windows. After this simulation the recommendations of the Machinery Usage Report were not to withdraw any of the least utilized machinery or labor (Table 4.20) because they were either unique object-items on the farm and did not have any complementary unit to substitute for them or they had a reasonably good utilization level. Some additional runs were made by removing some of the least utilized object-items (not recommended for withdrawal) to test the accuracy of recommendation. In these runs there were one or more operations not completed within the agronomic work windows which resulted in work area less than the cultivated area.
PAGE 191
180 Yield Estimation System This component of the decision system estimates the production of one or more crops grown on the farm. The knowledge-bases developed utilizing IBSNAT crop models and "Dry" weather year (1954, Tallahassee, FL) showed little variation in the peanut yields and an inverted U-shaped distribution for soybeans yields for different weeks during their respective planting windows. These yield results for this particular location and year make it difficult to demonstrate the effect of delayed operations utilizing these knowledge-bases . As cotton is the major crop of the test farm (Davis farm), a hypothetical distribution (Figure 3.16) of yield response to planting weeks within its agronomic window was assumed and a knowledge-base was developed varying the yield from 600 Kg/ha to 800 Kg/ha within the planting window utilizing this distribution. This knowledge-base has been utilized to demonstrate the functioning of the Yield Estimation System an integrated component of the decision system. Tables 4.21a and 4.21b present summary reports of this system for the runs with 12 and 10 daily work hours during April to June (the agronomic work window of cotton planting for the test farm) . As expected, the shorter work hours caused delays in planting cotton, thus reducing yields and overall farm profit from this crop. The total area under
PAGE 192
181 Table 4.21a Effect of scheduled work hours during planting period on yield, production and profits from cotton on Davis farm, a) 12 hours of daily scheduled work during planing window, b) 10 hours of scheduled daily work during planting window. Field Area (ha) Planting Yield Total Total Total Profit St. Fn. (T/ha) Prod. Sale Cost Total /ha -JdaysTon ($) ($) ($) ($) fieldl
PAGE 193
182 cotton on the test farm of 444.8 hectares produced 349.6 Tons and had net profit of $ 183/hectare with 12 hours of scheduled work. With the reduced work hours the production as well as net profit reduced because of lower yields form most of the fields. The overall production decreased to 340.1 Ton and net profit per hectare to $ 139.5 representing approximately 23% reduction in net profits. The test runs made to evaluate the recommendations of Expert Analysis System did not cause any change in the yield reports because in all these cases the shifts in timings were mainly for spraying operations to which the crop yield knowledge-bases are not currently designed to respond to. However, it is possible to modify them if appropriate information is available. Integrated Decision System The integration of the four components: Information Management, Operations Simulation, Expert Analysis and Yield Estimation Systems in a seamless manner has been successfully performed under the umbrella of FARMSYS. FARMSYS acts a controller for all four components which make use of common knowledge-bases stored in the form of dynamic databases of PROLOG. It can be utilized as decision-aid for a variety of farm systems under different climatic conditions. A team of experts who evaluated the professional qualification of FARMSYS found its components and logic
PAGE 194
183 captured in them adequate designed and widely applicable for a variety of fanning situations. Four components of FARMS YS functioned correctly, intelligently and in harmony with one another on the Davis farm knowledge used as a test farm for their operational verification. The Operations Simulation successfully simulated farm operations for complete cropping season and responded, as expected, to the variations in scheduled work hours and to the withdrawal of machinery and laborers. The Expert Analysis System has several ways to interact with the user to help him improve the productivity of his farm system. Its different components successfully imitated the behavior of machinery management expert (s) and acted according to the heuristics captured in them. The Machinery Usage report was able to identify the machinery and labor, not very important to the current farming system of the test farm. The Accumulated Work report and Operations Analysis report respectively provided the detailed analysis about the usage and the operations carried out by object-items recommended for withdrawal by the Machinery Usage report. This analysis was helpful in making final decisions about their withdrawals which were accurate and effective in reducing machinery and labor on the test farm. The decisions made after these recommendations demonstrated the possibility of reducing machinery and labor force from the farm without
PAGE 195
184 significantly affecting the timeliness of the majority of farm operations (Table 4.22). The Yield Estimation system responded successfully and accurately to the variations in scheduled work hours during April to June. The lower scheduled work hours during this period resulted in delayed planting of cotton on most fields, thus reducing the cotton yields and profits from different fields. The changes in farm knowledge-bases for all of the above tests were carried out using the Information Management System, thus proving its successful functioning as an integral component of FARMSYS, a knowledge-based decision support system for multi-crop production systems.
PAGE 196
185 Table 4.22 Comparison of machinery and labor resources on Davis farm available and recommended by FARMSYS Available List Recommended List Implements Operators Tractors (HP) DiskHarrow
PAGE 197
CHAPTER V CONCLUSIONS AND RECOMMENDATIONS The principal objective of this dissertation 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 was successfully accomplished utilizing knowledge engineering concepts of artificial intelligence. It has opened up a new horizon for developing decision-aid systems for complex agricultural problems. This new approach permitted seamless integration of simulation and knowledge systems, including their necessary databases. The use of PROgramming in LOGic (PROLOG) for engineering farm knowledge facilitated simulating field operations in an object-oriented manner. The inferencing capability of PROLOG were utilized to incorporate several expert systems within the simulation to make heuristic decisions and other types of searches at various stages of simulation. The object-oriented approach to simulation helps in capturing system's knowledge and depicting its dynamic behavior in a much more realistic manner than the conventional approaches to simulation. This 186
PAGE 198
187 approach also permits easy modifications and upgrades in the program code because of its modular structure. An operational scale decision-support system, FARMSYS, consisting of an intelligent information management system, an object-oriented operations simulation, an expert analysis system and a crop yield estimation system was designed and constructed. It was also evaluated for its professional qualifications and operational capabilities using a real farm knowledge set. The structure of the simulation in two distinct components: farm and regional knowledge, and simulation procedural knowledge has resulted in a versatile and flexible system which can be adjusted for a variety of farming situations ranging from highly mechanized farm (such as Davis farm) to a subsistence labor intensive farm with no mechanization at all. The encouraging results of the evaluation session for the professional qualifications of FARMSYS by a team of experts and verification of its operational capabilities through the use of a real farm knowledge set clearly indicate the possibility of using it as a decision-aid tool for planning and managing farming operations under a variety of farm situations. The concept of seamless integration of simulation and expert systems and their ability to use common knowledge-bases can be used for a variety agricultural and industrial applications.
PAGE 199
188 A few additional thoughts to further enhance the capabilities of FARMSYS as a decision-aid tool are presented below. 1) This research was mainly directed to handle the crop production component of a farm system. Most farms, especially small scale enterprises also have animal production as an integral component of their farming systems. The inclusion of an animal component in the representation of farm knowledge would result in a more practical farm model and decision-aid. 2) The scheduling of work hours for simulating field operations are currently adjusted on the global basis for the whole farm. All farm object-items are available for the entire cropping season and work the same number of hours for a given day. In real world situation, many farms have varying work hours for different members of their labor crew and even hire extra labor and machinery to meet their seasonal peaks. This can be achieved by assigning a list of work hours to each item of machinery and laborer class of the farm. This would permit adjusting scheduled work hours for each of them individually and also inclusion of custom hiring in and out of extra machinery and labor during critical periods of the cropping season. 3) The actual work hours for an operation for a day are currently based upon its type, the scheduled work hours and rainfall of the day. However in the real world situation, the past and expected future weather play a very important role
PAGE 200
189 in fanner's decision for his working hours for the day. The inclusion of this factor would make the simulation more accurate. In addition, there is a need to employ some systematic studies to develop genuine heuristics which govern the actual work hours for different regions. 4) Most farmers are interested in estimating the cost of machinery and labor component in their crop production activities. The incorporation of this factor utilizing some of the existing packages or developing a specialized one for FARMSYS would improve its (FARMSYS) acceptability for commercial enterprises. This can be done by attaching another attribute (cost/hour) for each machinery and labor on the farm. 5) All agricultural operations for crop production are sequential. They can be carried out one after another. However, certain operations such as two consecutive applications of a pesticide may require a minimum time delay between them to be effective. There is also a need to attach a factor of importance to different operations. This factor then would decide for the continuation of subsequent operations if any of the earlier operations have failed completely or partially. It would avoid the situation of not harvesting a field which has been planted, but could not cultivated.
PAGE 201
190 All these can be achieved by assigning some additional attributes to the operations object-class. 6) The effect of delayed harvesting on yield loss is not included in the crop models utilized for generating crop yield knowledge-bases for the Yield Estimation System. Therefore, there is a need to develop functions and/or expert knowledgebases on yield losses due to a late harvest of different crops under various environments. 7) FARMSYS is currently designed for strategic planning and not for tactical management in real time. In addition, it is structured to handle a farm with a certain level of mechanization either through tractor or animal traction. However, its structure permits modifying to work as a tactical management tool and/or to handle labor intensive farming with no mechanization at all. For a tactical management decision-aid tool in real time the adaptation needed would be 1) to stop the simulation at pre-defined interval and save the current environment, 2 ) present the current situation to the user, 3) provide him with the opportunity to make decisions about further actions either from his own experience or based upon the recommendations from the Expert Analysis System, 4) letting the user make changes in the resource-base and/or management strategies and 5) picking up the saved environment and continuing for simulation with the new resource-base until the next pause stage.
PAGE 202
191 The adaptation of FARMSYS for labor intensive farming for subsistence agriculture of developing countries would require 1) defining a field with a number of crops simultaneously and operations list attached directly to the field rather than the individual crop, 2) the possibility of defining a list of farm laborers (family or hired) to carry out different operations and to allocate them to the field whenever that operation is carried out and 3) a built-in mechanism to estimate the operational capacity of the crew of laborers working for an operation based upon age and sex of these individuals.
PAGE 203
APPENDIX I KNOWLEDGE-BASES Crop Yield Knowledge-bases General format cropyld(CropName, Year of Simulation, Variety, Soil Type, Irrigation, Fertilization, Planting Week, DaysToMutrity, Irrigation, Yield) It would contain numerous entries depending upon the combinations of various management inputs. Hypothetical examples for the some crops of the test farm follow. cropyld( "Soybeans", "Dry", "Kirby", "Sandy Loam", "Notirrigated", "Fertilized", 19, 136, 0, 0.8) cropyld( "Peanut", "Dry", "Florunner", "Sandy Loam", "Notirrigated", "Fertilized", 14, 128, 0, 2.05) cropyld( "Wheat", "Dry-Dry", "FL302", "Sandy Loam", "Notirrigated", "Fertilized", 47, 145, 0, 5.8) Knowledge Generated by Information Manager The following are the contents of different farm files of Davis Farm used as a test farm for different components of FARMSYS . Farm File General format farm (Name , Location , Total Area , CultArea , Activity , Code) The farm file contains only one entry as follow. farm ( "DavisFarm" , "SantaRosa" ,400,400, "CropProduction" , " dvs") 192
PAGE 204
193 Labor File General format labor (Num, Name , Sex , FunctionList , AvailStatus) It contains 4 entries one for each labor. labor ("Laborer_l"," Jerry", "m", ["General"] , "Avail") labor ("Laborer_2"," Joe", "m", ["General"] , "Avail") labor ("Laborer_3", "Ray ","m", ["General"] , "Avail") labor ("Laborer_4", "Keith", "m", ["Genral"] , "Avail") Tractor File General format tractor (Num, Model , HP , OperatorList , AvailStaus) It contains 5 entries one for each tractor. tractor("Tractor_l","JD4450",148, ["Jerry"] , "Avail") tractor("Tractor_2","JD4430",125, ["Keith", "Jerry", "Joe"], "Avail") tractor ( "Tractor_3" , " JD2950" , 90 , [ "Joe" , "Keith" ] , "Avail") tractor ("Tractor_4","JD3 02 0", 70, ["Jerry", "Joe", "Ray", "Keith"] , "Avail") tractor ("Tractor_5","JD2 640", 70, ["Jerry", "Joe", "Ray", "Keith"], "Avail") Implement File General format implement (Num, Type , Name, Tractor List , Width, Speed, AvailStatus) It contains 25 entries one for each implement, example for each type of implement follows. implement ("Implement_2" , "LandPrep" , "DiskHarrow" , [ "Tractor_l" , "Tractor_2" ] , 4 . 74 , 7 , "Avail" ) implement (" Imp lement_5", "PlantProtection", "SCultivator " , [ "Tractor_3 " , "Tractor_4 " , "Tractor_5"] , 3.6,7, "Avail") implement ( "Implement_14" , "PlantFerti" , "GeneralPLanter" , [ "Tractor_3 " ] , 3 . 6 , 8 , "Avail" ) implement ("Implement_2 2" , "Harvesting" , "PeanutCombine" , [ "Tractor_l" ] , 1 . 8 , 3 . 5 , "Avail" )
PAGE 205
194 Crop File General format crops (Num, Name , OperationsList ) The crop file contains 8 entries, 2 for each crop to account for two years, example for one year entry for each crop follow) crops ("Crop_3" , "Wheat" , ["Fertilize" , "Harrowing" "Plowing", "Planting", " Fert iSpr ead ing " "Harvesting"]) crops ("Crop_7", "Soybeans", ["Fertilize", "Harrowing" "Bedding" "Planting", "Cultivation!", "Cultivation2" "Cultivation3", "Sprayingl", "Spraying2" "Harvesting"]) crops ("Crop_2", "Cotton", ["Fertilize", "Harrowing" "Plowing", "Planting", "Sprayingl", "Cultivation!" "Spraying2", "Cultivation2" , "Sprayings" "Cultivations", "FertiSpreading", "Spray ing4" "Sprayings", "Sprayings", "Harvesting" , "Mowing" ] ) crops ("Crop_4", "Peanut", ["Fertilize", "Harrowing" "Plowing", "Planting", "Cultivation!", "Spraying!" "Cultivation2" , "Spraying2", "Spraying3" "Spraying4" , "Sprayings" , "Harvesting"] ) Field File General format fieldi(Num, Name, CultArea, SoilType, CropList, VarietyList, MaturityDaysList , FertilizationLevelList , IrrigationStatus, Operator forlrrigat ion, Costof Product ionPerHectList, SalePricePerTonList, AvailStatus) It contains 23 entries, one for each field, example of two fields follows. fieldi("Field_!", "field!", 20, "SandyLoam", ["Cotton", "Wheat"], ["DPL4!", "FL302"], [150, 165], ["Fertilized", "Fertilized"], "Notlrrigated", "NotNeeded", [750,125], [1200, !!0], "Avail") fieldi("Field_!2", "field!2", 2.4, "SandyLoam", ["Cotton", "Cotton2"], ["DPL90" , "DES119" ] , [150,150], ["Fertilized", "Fertilized"], "Notlrrigated", "NotNeeded", [750,750], [1200,1200] , "Avail")
PAGE 206
195 Operation File General format operations (Type, Name, Crop, EarlistStartTime, LatestFinishTime, WorkHrsCondList, ImpList, Eff) It contains 84 entries, one for each operation example for planting operations for different crops follows. operations ( "PlantFertiOps" , "Planting" , "Soybeans" , 136, 182, [[0,3,1], [3,8,0.5]], [ "Planter_77" ] , 0.76) operations ("PlantFertiOps", "Planting", "Wheat", 320, 366, [[0,3,1], [3,8,0.5], [ "GrainDril" ] , 0.76) operations ("PlantFertiOps", "Planting", "Cotton", 106, 161, [[0,3,1], [3,8,0.5]], ["Planter_77"] , 0.76) operations ("PlantFertiOps", "Planting", "Peanut", 106, 121, [[0,3,1], [3,8,0.5]], ["Planter_77"] , 0.76) T ype File General format type(EntityName,ItemList) It would contain variable number of entries depending upon the farm size and its activities. The contents of this file of the test farm are listed below. type("opsimplementtype", ["LandPrep", "PlantFerti", "PlantProtection" , "Harvesting" ] ) type("LandPrepOps", ["Fertilize", "Bedding", "Harrowing", "Plowing", "Mowing" , "End" , "AddNewItem" , "DeleteAnltem] ) type ("PlantFertiOps", ["End", "FertiSpreading", "Planting"]) type ( "PlantProtectionOps" , [ "Spray ing7" , "Cultivation4" ,"Sprayingl", "Spraying2", "Spraying3", "Spraying4", "Spraying5", "Spraying6", "Cultivation!", "Cultivation2", "Cultivation3", "AddNewItem", "DeleteAnltem"]) type ( "HarvestingOps" , [ "Harvesting" , "End" ] ) type("LandPrepImp", ["FertiSpreader", "Ridger", "DiskHarrow","DiscPlow", "MBPlow", "BottomPlow" , "MBPlowl" , "AddNewItem" , "DeleteAnltem" ] ) type("PlantFertiImp", [ "Planter_77" , "CottonSeeder" , "GeneralPLanter", "FertilizerSpreader", "AddNewItem" , "DeleteAnltem" ] )
PAGE 207
196 type("PlantProtectionImp", ["SCultivator", "MCultivatorl" , •'MCultivator2 " , "LBCultivator" , "PCultivator", "Sprayer", "PDSprayer", "PDSprayer2", "SprayCoupe", "AddNewItem" , "DeleteAnltem"] ) type("HarvestingImp", ["BMower", "GeneralGrainCombine" , "PeanutCombine", "CottonPicker", "AddNewItem", "DeleteAnltem"]) type ("crop", ["Cotton", "Wheat", "Cotton2", "Soybeans", "Soybeans2", "Corn", "Peanut", "AddNewItem", "DeleteAnltem"]) type ("Soybeans", ["Kirby", "Bragg", "Centennian" , "AddNewItem" , "DeleteAnltem" ] ) type ( "Peanut" , [ "Florunner" , "AddNewItem" , "DeleteAnltem" ] ) type ( "Cotton", ["S0CS4 53", "DLP90", "DES119", "SOS106", "DLP41", "AddNewItem", "DeleteAnltem"]) type ( "Wheat" , [ "FL302 " , "AddNewItem" , "DeleteAnltem" ] ) type ( " irrigation" , [ " Irrigated" , "Notirr igated" ] ) type("soiltype", [ "SandyLoam" , "SiltLoam", "ClayLoam", "FineSand"]) type ("fertilization", ["Fertilized" , "NotFertilized"] ) type ("activity", ["CropProduction", "Livestock", "MixedFarming" ] ) Knowledge Utilized by Information Manager Screen Files General format field (Name , Type , StartRow, StartCol , Length) txtf ield ( StartRow , StartCol , Length , Text) windowsize (Right, Width) The contents of the screen file for constructing screen layout for collecting General Farm information are listed below. f ield ( "action", str, 6, 35, 25) field ( "name" , str , 8 ,28,29) field ( "location" , str ,10,28,23) field ( "tarea" , real , 12 , 35 , 11) field ( "cultarea" , real ,14,35,11) field ( "activity" , str, 16,47,30) field ( " f ilesexten" , str, 18,53,4) txtfield(8,12,12,"Name of Farm") txtf ield ( 10 , 12 , 8 , "Location" ) txtf ield ( 12 , 12 , 14 , "Total Area (ha) " ) txtf ield (14,12,19, "Cultivated Area (ha) " ) txtfield(4,0,16," ") txtfield(2,0,10," »•)
PAGE 208
197 txtfield(0,ll,l, '•*••) txtfield( 1,11,1,"*") txtfield(2,ll,l,"*") txtfield(3,0,67," * k****************************************************'^ txtfield(0, 16,48, "FARMSYS-A Decision Support System for Multi-Crop") txtfield(0,66,3," *••) txtfield(l,66,3," *") txtfield(3,68,l,"*") txtfield(l,30,20," Production Systems") txtfield(2,13,56, " Farm Information Manager-General Farm Information *") txtfield(6, 12,23, "Action being Performed ") txtfield(18,12,35,"Farm generally known as (3 letters)") txtfield(16,12,31,"Press to Select Activity") windowsi2e(20,77)
PAGE 209
APPENDIX II MINI -CONFERENCE FOR FARMSYS QUALIFICATION PROGRAM Decision Support System with Logic Programming Agricultural Engineering Department University of Florida November 14, 1988 8:30 a.m. -Purpose of the meeting, and schedule adjustments Dr. Peart 8:45 a.m. -Introduction to FARMSYS and to the concepts of "Qualifying" rather than "Validating" knowledge-based systems Harbans Lai and Dr. Peart 9:30 a.m. Orange juice break 9:45 a.m. Demonstration of FARMSYS and introduction to questionnaire Harbans Lai and Dr. Peart 11:15 a.m. -Operations management research, MACH II and U.S. Sugar Dr. W. D. Shoup 11:45 a.m. Lunch 1:15 p.m. Qualification Session with FARMSYS using questionnaire Harbans Lai and Dr. Peart 2:45 p.m. Break 3:00 p.m. Review of the international DSSAT program Dr. Shrikant Jagtap 3:45 p.m. Open Session (Discussion on approaches and procedures for evaluating knowledge-based systems) 5:00 p.m. Adjourn 198
PAGE 210
199 Table II-l Participants Names and Addresses Name Address Dr. John Ogilvie Dr. Bill Chancellor^ Dr. Maurice R. Gebhardt^ Director, School of Engineering University of Guelph, Ontario, Canada Professor, Dept. of Agric. Engg. University of California, Davis, CA 95616 Professor, Agric. Engg. Bldg. USDA-ARS, University of Missouri Columbia, MO 65211 Dr. M. Zohadie Bardaie Dr. Kenneth L. Von Bargen^ Dr. Thomas S. Colvin^ Dr. Garry D. Bubenzer^ Professor, Agric. Engg. Dept. University Pertanian Malaysia 43400, Serdang, Selangor, Malaysia Professor, Agric. Engg. L. W. Chase Hall, Univesity of Nebraska Lincoln, NE 68583-0726 Agricultural Engineer, USDA/ARS 213 Davidson Hall, Iowa StateUnivesity Ames, lA -50011 Chairman, Agric. Engg. Dept. University of Wisconsin 460 Henry Hall, MadisonWI 53706 Dr. R. K. Sprinkel Assoc. Professor, Int. Pest Management Entomology and Nematology, Univ. of Florida Gainesville-FL 32611
PAGE 211
200 Table II-l — continued Name Address Dr. Peter Hildebrand Dr. Larry Bagnell Professor, FSR/E Food and Resource Economics Univ. of Florida Gainesville -Fl 32611 Professor Dept. of Agric.Engg. Univ. of Florida Gainesville -FL 32611 Dr. M. Peart Dr. J. W. Jones Grad. Research Professor Dept. of Agric.Engg. Univ. of Florida Gainesville -FL 32611 Professor Dept. of Agric. Engg. Univ. of Florida, Gainesville -FL 32611 1Participants who filled in the questionnaire on FARMSYS
PAGE 212
201 FARMSYS Evaluation and Qualification Harbans Lai and R. M. Peart Please indicate the extent to which you agree or disagree with the different statements. 1 — Strongly agree 2 — Agree 3 — Undecided 4 — Disagree 5 — Strongly disagree Evaluation of different components 1. Information Manager This component is designed to collect information about a new farm and let the user make changes in the already existing farm. The important requirements for this component are ease and user-friendliness in collecting and updating farm information and checking the integrity of the supplied information. Let us see if we have been able to incorporate these features effectively. Please evaluate screen layouts for collecting information about different farm entities. STRONGLY STRONGLY AGREE DISAGREE Screen layouts for collecting information about different farm entities is well designed. 4 5 Mechanism of letting user develop and maintain knowledge-base specific to his farm is unique for FARMSYS. 4 5 Mechanism of retrieving, presenting old information, letting user make changes and saving new information are adequately designed. 4 5 Information Manager is qualified to let user develop new farm and modify information about existing farm. 1 2 4 5
PAGE 213
202 2. OPS-SIMULATOR The Ops-Simulator is designed to simulate the field operations to predict the scheduling of different field operations. The effectiveness of Ops-Simulator in depicting the real world situation depends on its formulation and incorporation of the factors controlling these operations in as realistic a manner as possible. The key features of this component have been identification of different components of an operational knowledge of a farm, its representation and manipulation to generate new knowledge which can be then utilized by other components of FARMSYS. Please evaluate the approach to simulating field operations. 2 . 1 Knowledge-Bases STRONGLY STRONGLY AGREE DISAGREE The semantic representation of farm knowledge (to be explained) adeqpiately expresses the farm knowledge for multi-crop production system. 12 3 4 5 The components of the following knowledge-bases are adequately structured (to be explained) . a) Farm Knowledge: Farm Labor Tractor Implement Equipment Crops Fields Operations b) Regional Knowledge: Expert File Weather File c) Output Reports: Work Reports 12 3 4 5 No-Work Reports 12 3 4 5 Summary Report 12 3 4 5 Please evaluate the following features of the Ops-Simulator for farm operations simulation modelling. Do they allow us to develop a simulator which would predict the system's behavior in a more accurate and realistic manner than most conventional simulators. Indicate to what extent you agree or disagree with the following statements. 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5
PAGE 214
203 2.2 Simulation Methodology STRONGLY STRONGLY AGREE DISAGREE The semantic representation of the farm knowledge has facilitated keeping farm knowledge separate from code of the simulation. It has resulted in a versatile and scale neutral simulator which can be utilized for different types of farm settings. The assigning of more than one operator to a tractor and more than one tractor to an implement is more realistic for farm operations modelling than generally captured in conventional simulators. 1 The checking of conditions for the field operations is carried out more rigorously than most conventional simulator using procedural languages. It has more realistic criteria for deciding actual work hours for the day's work. It uses more robust and realistic mechanism for finding the available machinery set (Implement, Tractor and Operator) than conventional simulators. The facility of adjusting the scheduled work hours for the farm prior to start of simulation is important. 1 The economics of operations is not considered in enough detail. Scheduled work hours are decided for whole farm rather than for individual operator (s) or tractor (s) .
PAGE 215
204 The expected future weather while deciding actual work hours is not considered. STRONGLY STRONGLY AGREE DISAGREE 12 3 4 5 The Ops-Simulator is qualified to simulate field operations for multi-crop production systems. 12 3 4 5 Please help identify additional weaknesses and strengths of the Simulator in comparison to other similar programs familiar to you. (Use back side of page if needed.) a) Weaknesses 1) 2) b) Strengths 1) 2) 3. YLD-ESTIMATOR The yld-estimator is designed to estimate the overall production and net profit from different crops grown on the farm. The power of this component depends upon the power of the mechanism utilized to predict yields of different crops grown on the farm under different management inputs. We utilized the IBSNAT crop models for making these estimations. However, we are interested in identifying other ways to predict crop yields. Please help us to do that.
PAGE 216
205 STRONGLY STRONGLY AGREE DISAGREE It is good to have yld-estimator as a component of the FARMSYS. However, its acceptance as a machinery management tool would not be affected significantly without it. 1 The use of crop simulation models for predicting crop yields for the farm level is not a good idea because they are not designed for this purpose. 1 The following features of the yldestimator are adequately structured: Screen layout for letting user select field (s) /crop (s) Structure and contents of the final report The yld-estimator is qualified to make yield and net return predictions if appropriate crop model (s) are used. 4. EXPERT ADVISOR The EXPERT ADVISOR is designed to analyze the reports produced by the Ops-Simulator in context of the farm resource-base (availability of the labor and machinery) and other management decisions (Scheduled Work Hours and Allotment of machinery and power sources to different operations) and make recommendations to the user on efficient and cost effective machinery management options. There are endless possible ways of analyzing the simulation results. We have taken one approach (to be explained) which may not be the best one. Secondly, the criteria utilized in analyzing machinery usage and delays in operations is further based upon some assumptions which are our intelligent guesses. Please judge the importance of these reports and evaluate the criteria utilized in their preparation. In addition, please identify the nature and format of some additional reports which would increase the power of expert advisor.
PAGE 217
206 4 . 1 Individual Reports Evaluation a) Machinery Usage Report Objective To identify the least utilized object-item of the selected machinery type or laborers and develop a recommendation about whether or not to keep it. This report is designed to identify the excess machinery available on the farm. Please give your opinion. STRONGLY STRONGLY AGREE DISAGREE The objective of the report is sufficiently strong and impressive and users will make intensive use of this report. 12 3 4 5 The criteria (to be explained) utilized for identifying the least utilized objectitem are adequate and realistic. 1 2 The criteria (to be explained) utilized for deciding recommendation about least utilized object-item are adequate and realistic. 1 2 List other criteria which could be employed for developing recommendations for the least utilized object-item. a) b) c) b) Operations Analysis Report Objective 1) Identification of Problems To identify operations which had delays in their start and/or finish, along with the factors responsible for these delays. This report is designed to identify bottleneck in timely completion of the different operations such as insufficient scheduled work hours, low working speed, or smaller size machinery on the farm.
PAGE 218
207 STRONGLY STRONGLY AGREE DISAGREE The objective of the report is sufficiently strong and impressive and users will make intensive use of this report. 12 3 4 5 The criteria (to be explained) utilized for identifying problematic operations is not adequate and needs improvement. 12 3 4 5 The break-up of the timing window is ok. 12 3 4 5 List other criteria which could be utilized for the purpose (including criteria for dividing timing window) . a) b) c) 2) Developing Recommendations The report also develops cost effective recommendations to minimize these delays. The criteria (to be explained) utilized to make the following recommendations are adequate and realistic. STRONGLY STRONGLY AGREE DISAGREE Increase Scheduled Work hours 12 3 4 5 Increase Speed of operation 12 3 4 5 Increase Working width 12 3 4 5 Suggest methods for improving the above recommendations. 1) 2) 3)
PAGE 219
208 c) Accumulated Work Report Objective To present an accumulated work report for any combination of object-items of farm entities over any desired interval of time period. This report is designed to let users know about the intensity of usage of different object-items of various farm entities. Using this report one can determine how many hours Tractor_l worked on Soybean Fields during the period January 1 to Jun 15 etc. STRONGLY STRONGLY AGREE DISAGREE The objective of the report is sufficiently strong and impressive and users will make intensive use of this report. The interactive mode for letting users select different farm object-items and time interval is adequately designed. The results of this report are presented in the form of two sub-reports namely Summary Reports and Detailed Report (to be explained) . Please evaluate these reports. Both reports are essential 12 3 4 5 Both reports are logically presented. 12 3 4 5 List other types of information which could be included to make these reports more useful. a) b) c)
PAGE 220
209 4.2 Overall Evaluation The Expert Advisor presently prepares the three reports evaluated individually earlier. However, we would like to have your overall impression about these reports. STRONGLY STRONGLY AGREE DISAGREE The Expert Advisor is an important component of FARMSYS. 12 3 4 5 The Expert Advisor is qualified to carry out its desired functions. Please list additional reports and their objectives which you would like to see included in Expert Advisor. a) Title: Objective: b) Title: Objective: 5. FARMSYS Finally, we would like to have your overall impression of FARMSYS as an integrated decision-aid tool. FARMSYS is qualified as a decision-aid tool for machinery management for multi-crop production system. 12 3 4 5 Things You Would Like To See Added To FARMSYS ITEM: Things You Would Like To See Deleted From FARMSYS ITEM: Name: Address :
PAGE 221
210 Non-Structured Responses about FARMSYS Weaknesses 1) Economic factors need to be incorporated more 2) Soil consideration on farming not adequately considered 3) Some obvious refinements not presented or communicated 4) Does not allow for information input from out side or even from internal previous day simulations in deciding what will be done on the following day. 5) Lack of use of established algorithms 6) Inability to adapt to tactical planning Strengths 1) Comprehensive in selection process 2) Concept of no-work report is very good 3) structured approach 4) Excellent framework. Most suggestions made would be good and desirable but not essential. 5) global approach 6) Tries to include a broad range of factors and data. 7) Ease of setting up 8) Flexibility of reports 9) Adaptability to diverse areas of the world. 10) The mechanism of user information input Suggestion 1) User definition of agronomic work window and critical timing of operations. 2) Include cash flow report, to keep track of cash requirement over time. 3) Looking at impact of soil beyond soil type. 4) Distinction between management and planning tool. They need different types of inputs. 5) Flexibility to account for individual criteria about machinery usage report and operations analysis report. 6) Need to accommodate more tools 7) Amount of resources needed by week or by month (fuel, labor etc.) 8) More rigorous role on soil/water/machinery management interactions. 9) multi-operations in field at same time or sub-divide the fields to allow this. 10) Utilize weather data to set initial time for operation to begin. 11) Include operation economics, cash flow projection and specific effect of operations upon profit. 12) Age of the implement for deciding recommendations about the machinery usage report, which gives idea of need for keeping back up. Other factors suggested for this report are a) potential decrease in market of machine value with
PAGE 222
211 time, b) need for the machine as back up. 13) In critical periods day could be broken down to 2 hours interval or the next job could start immediately even though it is not the start of a new day. 14) Make facility to put more than one tool in same field for the same operation or subsequent operations. 15) Add economic data for each object-item e.g. US$/hr for each worker and for each tractor and implement. 16) Graphics like Gnat chart to show actual happening vs. planned. 17) Realignability of windows based upon events which have developed on day to day basis. 18) The window should always be elongated ( even as nonpreformed choice) in order to get the land plantedno matter what. 19) A system that allows the daily choices to be made based upon the state of the fields, equipment, crop, operators and weather on the previous day. 20) Considering down time of first choice tractor, implement, etc. 21) Prepare maintenance report for tractors and implements. 22) Allow part time labor and machinery Concerns 1) The user setting all the windows for work 2) I am not sure of validity of this evaluation. Time too much of limitation. 3) What about yesterday's work conditions influencing today's work. 4) I am troubled by lack of use of the established algorithm which have been field validated. 5) I really like its data input system and its concept of priority. I think its use of algorithm for appropriate tasks such as work days available need to be evaluated.
PAGE 223
REFERENCES Addis, T. R. 1985. Designing knowledge-based systems: Knowledge for the new generation computers. PrenticeHall, Englewood Cliffs, NJ. Adelsberger, H. H. 1984. PROLOG as a simulation language. In Proc. of the 1984 Winter Simulation Conf. ed. S. Sheppard, V. Pooch and D. Pegden. SCS, San Diego, CA. pp. 501-504. AAAI and ASAE. 1988. Integration of expert systems with conventional problem solving techniques in agriculture. Proc. of the Workshop, AAAI and ASAE. Aug. 10-12, San Antonio, TX. Barrett, J. R. , J. B. Morrison and L. F. Huggins. 1985. Artificial intelligence and expert systems in agricultural research and education. ASAE paper 85-5516. ASAE, St. Joseph, MI. Batchelor, W. D. , R. W. McClendon, J. W. Jones and D. B. Adams. 1987. An expert simulation system for soybean insect pest management. ASAE Paper 87-4501. ASAE, St. Joseph, MI. Beck, H. W. and J. W. Jones. 1988. Simulation and artificial intelligence concepts. Paper presented at the Expert Systems Workshop, Orlando, FL, Feb. 1988. ASAE, St. Joseph, MI. Bender, D. 1984. Hierarchical integration of simulation and linear programming to assess risk-efficient cropping systems. PhD Thesis. Purdue University, West Lafayette, IN. Bennett, T. B. , R. S. Sowell and R. E. Sneed. 1988. An expert system for irrigation planning and design. ASAE Paper 88-5021. ASAE, St. Joseph, MI. Boggess, W. G. , and C. B. Amerling. 1983. A bioeconomics simulation analysis for irrigation investments. S. Journal Agric. Econ. 16: 85-91. 212
PAGE 224
213 Boote, B. J. and Jones, J. W. 1986. Application of and limitations in crop growth simulation models to fit crops and cropping systems to semi-arid environment. Depts. of Agronomy and Agric. Engg. University of Florida, Gainesville, FL. Borland. 1986. Turbo PROLOG: The natural language for artificial intelligence. Borland International Inc. , Scotts Valley, CA. Borland. 1987. Turbo PROLOG Tool Box: User's guide and reference manual. Borland International Inc., Scotts Valley, CA. Brown, T. L. 1974. Farm machinery selection by use of a zero-one mixed integer linear programming. MS Thesis. Purdue University, West Lafayette, IN. Bulkeley, W. M. 1986. Expert systems are entering into main stream of computers. Technology. The Wall Street Journal, Dec. 5. 1986. Burrows, W. C. and J. C. Siemens. 1974. Determination of optimum machinery for Corn-Soybean farms. Trans, of the ASAE 17(6) :1130-1135. Candler, W. 1968. A linear program for selecting a corn production system. Conf. Proceedings: Computers and Farm Machinery Management, Dec. 1968. ASAE St. Joseph, MI. pp. 20-21. Chen, L. H. 1986. Microcomputer model for budgeting and scheduling crop production. Trans. of the ASAE 29(4) :908-911. Chen, L. H. 1987. A microcomputer model for selection of machines and tractors. ASAE Paper 87-1050. ASAE, St. Joseph, MI. Chen, L. H. and R. W. McClendon. 1985. Soybean and wheat double cropping simulation model. Trans, of the ASAE 28(1) :65-69. Citrenbaum, R. , J. R. Geissman and R. Schultz. 1987. Selecting a shell. AI EXPERT. 2(9): 30-39. Coulson, R. N., L. J. Folse and D. K. Loh. 1987. Artificial intelligence and natural resource management. Science 237:262-267.
PAGE 225
214 Davis, J. R. and P. M. Nanninga. 1985. GEOMYCIN: Towards a geographic expert system for resource management. Journal of Environment Management 85(21) :377-390. Digitalk. 1986. Smalltalk/V: Tutorial and program handbook. Digitalk Inc., Los Angeles, CA. Donahue, D. W. , R. S. Sowell and N. T. Powell. 1988. An expert system for diagnosing diseases of tobacco. ASAE Paper 88-5022. ASAE, St. Joseph, MI. Edwards W. and Michael B. 1980. Machinery selection considering timeliness losses. Trans, of the ASAE-1980. pp 810-815,820. Eisgruber, L. M. 1968. Where do we go from here ? Panel discussion. Conf. Proceedings: Computers and Farm Machinery Management, Dec, 1968. ASAE St. Joseph, MI. pp 52. Elderen E. van. 1981. Scheduling of field operations: Research report. Inst, of Agric. Engg. IMAG, Wageningen, Netherland 81(3) :865-871. Elderen, E. van. 1987. Scheduling farm operations: A simulation model, Pudoc Wageningen, Netherland. Elmaghraby, A. S. and V. Jagannathan. 1986. An expert system for simulationists. In: AI Graphic and Simulation, ed. Graham Birtwistle. Soc. for Comp. Simu. San Diego, CA. pp 106-109. Engel, B. A., D. D. Jones and J. R. Wright. 1988. Selection of an expert system development tool. ASAE Paper 885017. ASAE, St. Joseph, MI. Engel, B. A., D. B. Beasley and J. R. Barrett. 1988a. Knowledge engineering in soil erosion. ASAE Paper 882140. ASAE, St. Joseph, MI. Fan, I. S. and P. J. Sackett. 1988. A PROLOG simulator for interactive flexible manufacturing systems control. Simulation 50(6) :239-247. Feigenbaum, E. A. and P. McCorduck. 1983. The fifth generation: artificial intelligence and Japan's computer challenge to the world. Addison-Wesley, Reading, MA. Fisher, E. L. 1986. An Al-based methodology for factory design. AI Magazine, Fall 1986. pp. 72-85.
PAGE 226
215 Flowers, E. B. 1988. Failing with grace. Turbo Technix. The Borland Language Journal l(5):76-85. Futo, I. and T. Gergely. 1986. TS-PROLOG a logic simulation language, TRANS, of the SCS, 3(4): 112-119. Futo, I. and T. Gergely. 1987. Logic programming in simulation, Trans, of the Soc. for the Comp. Simu. 3(3) :195-216. Gaines B. R and M. L. G. Shaw. 1986. Expert systems and simulation. In: AI Graphic and Simulation. ed. Grahm Birtwistle. Soc. of Comp. Simu. San Diego, CA. pp. 95101. Gauthier, L. and R. Kok. 1988. A microcomputer-based farm management/ operating system. Can. Agric. Eng. 30(1) :6976. Geyer, F. P., R. M. Peart and W. H. M. Morris. 1963. Bottlenecks in handling corn at harvest. ASAE Paper 63829. ASAE St. Joseph MI. Gibson, H. G. , D. D. Jones, J. R. Barrett and C. H. Shih. 1986. Timber harvesting equipment selection: An expert system. ASAE Paper 86-1604. ASAE, St. Joseph, MI. Glunz, D. J. 1985. Comparative analysis of Florida citrus harvest systems. MS Thesis. University of Florida, Gainesville, FL. Gui X. and J. C. Siemens. 1986. An optimum machinery selection model for corn soybean farm. ASAE Paper 861523. ASAE, St. Joseph, MI. Halterman, S. T. , J. R. Barrett and M. L. Swearingin. 1986. Expert systems development stages: Double cropping as an example. ASAE Paper 86-4516. ASAE St. Joseph, MI. Hart, R. D. 1984. Hierarchical agricultural systems. In: Prosepectives on farming systems research and extension, ed. Peter E. Hildebrand. Lynne Rienner Publishers, Boulder, CO. pp. 29-32. Hayes-Roth, F. , D. A. Waterman and D. B. Lenatm. 1983. Building expert system. Addison-Wesley Publishing Co. Inc. , Reading, MA.
PAGE 227
216 Helms, G. L. , J. W. Richardson, M. E. Rister, N. D. Stone, D. K. Loh. 1987. COTFLEX: A farm-level expert system to aid farmers in making farm policy decisions. Paper presented at the 1987 Annual Meeting of Am. Agric. Econ. Assoc. East Lansing, MI. Hetz, E. J. and M. L. Esmay. undated. A field machinery selection model for wheat producers in the Andes PreCordillera of south central Chile. Agric. Engg. Dept. Michigan State University, East Lasting, MI. Hoogenboom, G. , Jones, J. W. and J.W. White. 1987. Use of models in studies of drought tolerance. Paper presented at the Workshop on Drought in Dry Beans. October 1987. Centre Internacional da Agricultura Tropical, Cali, Colombia. IBSNAT. 1986. Decision support system for agrotechnology transfer (DSSAT) : Documentation for IBSNAT crop models input and output files. Version 1.0. Technical Report 5. International Benchmark Sites Network for Agrotechnology Transfer, University of Hawaii, Honolulu, HI. InelliCorp. 1988. How to get started in AI: IntelliCorp's guide to getting off on the right foot. IntelliCorp Inc., Mountain View, CA. Jones, D. D. and L. A. Hoelscher. 1987. Applications of expert systems in extension engineering. ASAE Paper 875021. ASAE, St. Joseph, MI. Jones, J. W. , K. J. Boote, S. S. Jagtap, G. Hoogenboon, and G. G. Wilkerson. 1988. SOYGRO 5.4: Soybean crop growth simulation model-user's guide. Florida Agri. Expt. Sta. Journal No. 8304. Inst, of Food and Agric. Sci.. University of Florida, Gainesville, FL. Jones, J. W. , Pierce Jones, P. A. Everett. 1987. Combining expert systems and agricultural models: A case study. Trans, of the ASAE 30(5) :1308-1314. Jones, P., J. W. Jones, P. A. Everett and H. Beck. 1986a. Knowledge acquisition: A case history of an insect control expert system, ASAE Paper 86-5041. ASAE St. Joseph, MI. Jones, P., J. W. Jones, P. A. Everett, F. A. Johnson and R. K. Sprinkle. 1986b. Development of an expert system for making insects control decisions in soybeans. Int. Conf. on Computers in Agric. Ext. Prog. Feb 1986. Orlando, FL.
PAGE 228
217 Jones, P. and J. Haldeman. 1986. Management of a crop research facility with a microcomputer-based expert system. Trans, of the ASAE 29 (1) :235-242 . Kalkar, S. and P. R. Goodrich. 1986. An expert system for animal waste management. ASAE Paper 86-4540. ASAE, St. Joseph, MI. Khuri, R. S., W. D. Shoup, R. M. Peart and R. L. Kilmer. 1988. Expert system for interpreting citrus harvest simulation. Applied Engineering in Agriculture. 4(3) :275-280. Kline, D. E., D. A. Bender, C. E. Van Donge, B. A. McCarl and J.K. Schueller. 1986. Machinery selection using farmlevel intelligent decision support systems. ASAE Paper 86-4519. ASAE, St. Joseph, MI. Kline, D. E., D. A. Bender, B. A. McCarl. 1987. Farm-level machinery management using intelligent decision support systems. ASAE Paper 87-1047. ASAE St. Joseph, MI. Konaka Toshio. 1987. Farm machinery utilization planning. AMA 18(3) :75-81. Kornecki, A. 1988. Simulation and artificial intelligence as tools in aviation education. In: AI Papers, ed. R. J. Uttamsingh. Soc. for Comp. Simu. , San Diego, CA. Simulation Series 20(1) : 121-126. Labiadh S. and J. C. Frisby. 1987. A simulation model to select alfalfa harvesting machines. ASAE Paper 87-1047. ASAE, St. Joseph, MI. Lai H. and L. C. Freire. 1984. Operational cost of animal-drawn agricultural implements in various sizes of farm holdings. Research Bulletin 21. CPATSA/EMBRAPA, Petrolina, Brazil. Lai, H., R. M. Peart and J. W. Jones. 1987. Expert systems for technology transfer. ASAE paper 87-5028. ASAE, St. Joseph, MI. Lemmon, H. 1986. Comax: An expert system for cotton crop management. Science 233:29-33.
PAGE 229
218 Link, D. A. 1967. Activity network techniques applied to farm machinery selection problem. Trans, of the ASAE 10(3) :310-316. Link, D. A. and C. W. Bockhop. 1964. Mathematical approach to farm machine scheduling. Trans, of the ASAE 7(1) :816. Loewer, O. J., M. F. Kocher and T. C. Bridges. 1988. An expert system for determining bottlenecks in on-farm grain processing systems. ASAE Paper 88-6073. ASAE, St. Joseph, MI. McKinion, J. M. and H. E. Lemmon. 1985a. Expert systems for agriculture. Computers and Electronics in Agriculture 1(1985) :31-40. McKinion, J. M. and H. E. Lemmon. 1985b. Symbolic computers and AI tools for a cotton expert system. ASAE Paper 855520. ASAE, St. Joseph, MI. Meyer, G. E. and R. B. Curry. 1986. Soybean production decision-making with the REALSOY Model. ASAE Paper 864507. ASAE, St. Joseph, MI. Miles, G. E. and Y. J. Tsai. 1987. Combine systems engineering by simulation. Trans. of the ASAE 30(5) :1277-1281. Moralee, D. S. 1986. The use of knowledge engineering in an industrial research environment A retrospect. Expert Systems and Knowledge Engineering, Elsevier Science Publishers, Holland, pp. 101-109. Morrison, J. B. 1985. Forthcoming role of artificial intelligence in agricultural science and education system. Executive Summary, Agricultural Communication Service. Purdue University, West Lafayette, IN. Moser, J. G. 1986. Integration of artificial intelligence and simulation in comprehensive decision-support system. Simulation 47(6) :223-229. Nagarajan K. , D. Singh and J. K. Wang. 1985. Optimum allocation of farm power resources in multi-crop farming systems. ASAE Paper 85-5056. ASAE, St. Joseph, MI. Nagarajan, K. , J. W. Mishoe and W. L. Currey. 1987. Development of an expert system for weed management in Soybean. ASAE Paper 87-9659. ASAE St. Joseph, MI.
PAGE 230
219 Neggahban, B. , R. C. Fluck and W. D. Shoup. 1988. Selection of lawn and garden tractors using an expert system. Applied Engineering in Agriculture 4 (3) :211-216. Nelson, T. and W. Bowers. 1968. What programs are operational now ? Conf. Proceedings: Computers and Farm Machinery Management, Dec. 1968. ASAE St. Joseph, MI. pp. 6-8. Newell, A. and H. A. Simon. 1963. GPS; A program that simulates human thoughts. In: Computers and thoughts, ed. E.A. Feigenbaum and J. Feldman. McGraw-Hill, New York, pp. 279-293. Nguyen, T A. , W. A. Perkins, T. J. Laffey and Deanne Pecora. 1987. Knowledge-base verification. AI Magazine, Summer 1987. pp 69-75. O'Keefe, R. 1986. Simulation and expert systems; A taxonomy and some examples. Simulation 46(1):10-16. O'Keefe, R. M. and J. W. Roach. 1987. Artificial intelligence approaches to simulation. J. Opl Res. Soc. 38 (8) :713-722 . Oren, T. I. 1986. Knowledge-bases for advanced simulation environment. Proc. Conf. on Intelligent Simulation Environments. Soc. for Comp. Simu. , San Diego, CA. pp. 16-22. Oren, T. I. and B. P. Zeigler. 1979. Concepts of advanced simulation methodologies, Simulation 32(3):69-82. Ozkan, H. E. and W. M. Edwards. 1986a. A farmer oriented machinery comparison model. Trans. of the ASAE 29(3) '.612-611 . Ozkan E. and W. Edwards. 1986b. Microcomputer software for machinery management. Proc. of the Int. Conf. on Computers in Agric. Ext. Prog., Orlando, FL. pp. 701-706. Ozkan, H. E., W. M. Edwards & A. Saulman. 1984. A machinery selection model for farmer decision-making. ASAE Paper 84-1521. ASAE, St. Joseph, MI. Paperback Software. 1985. VP-Planner: Spreadsheet flexibility with database power. Paperback Software International, Berkeley, CA. Pascoe, G. A. 1986. Elements of object-oriented programming. Byte 11(9) : 139-144.
PAGE 231
220 Peart R. M. and J. R. Barrett. 1979. The role simulation. In: Modification of aerial environment of plants, ed. B. J. Bar field and J.F. Gerber. ASAE Monograph (2). ASAE St. Joseph, MI. Peart, R. M. , J. R. Barrett and R. D. Smith. 1985. A cropping decision support system using artificial intelligence concepts. Agril. Engg. Dept. Purdue University, West Lafayette, IN. Peart, R. M. , H. Lai and J. W. Jones. 1988. Developing integrated decision support systems using PROLOG. Presented at the AAAI workshop on AI in Agriculture, Aug., 1988. San Antonio, TX. Pepper, J. 1986. Knowledge craft: An environment for rapid prototyping for expert systems. Paper presented at the AI for Automotive Industry Conference. March 1986. Detroit, MI. Phillips, J. J. and S. B. Harsh. 1987. An expert system application to the financial analysis of lender case farm records. Paper presented at the Annual Meeting of Am. Agric. Econ. Assoc. Lansing, MI. Plant, R. E. and T. L. Wilson. 1986. A computer based pest management aid for San Joaquin Valley cotton. Proc. of the Beltwide Cotton Conf., Nation Cotton Council of Amer. , Memphis, TN. pp. 22-24. Plant, R. E., L. T. Wilson, L. Zelinski, P. B. Goodell and T. A. Kerby. 1987. CALEX/COTTON: An expert system based management aid for California cotton growers. University of California, Davis, CA. Prerau, D. S. 1987. Knowledge acquisition in the development of a large expert system. AI Magazine, Summer 1987. pp 43-51. Pritsker, A. A. B. 1984. Introduction to simulation and SLAM II. Second Edition. John Wiley and Sons, New York, NY. Pritskar, A. A. B. and C. D. Pegden. 1979. Introduction to simulation and SLAM. Systems Publishing Corp. West Lafayette, IN. Reddy Y. V., M. S. Fox, N. Hussain and M. McRoberts. 1986. The knowledge-based simulation system. IEEE SOFTWARE, March 1986. pp 26-37.
PAGE 232
221 Rettinger, J. C. , G. E. Miles and G. E. Wilcox. 1987. Muskmelon production expert system. ASAE Paper 87-5029. ASAE, St. Joseph, MI. Rich, E. 1983. Artificial intelligence, McGraw-Hill Book Company, New York, NY. Rimmington, G. M. , R. Berger, D. J. Connor and T. A. McMohon. 1987. Expert systems and crop simulation modelling. Proc. of the Simulation Society Conf . , Melbourne, Australia, pp. 343-358. Roach, J. W. and R. S. Virkar. 1986. POMME: A computer based consultation system for apple orchard management using PROLOG. A technical report. Department of Computer Science and Applications, Virginia Polytechnic Institute and State University, Blacksburg, VA. Ruckman J. 1986. A model for computer integrated farming system. ASAE Paper 86-1519. ASAE, St. Joseph, MI. Rumsey, J. W. , L. Gautz and W. J. Chancellor. 1986. Increasing farm machinery cost effectiveness in California. ASAE Paper 86-1520. ASAE, St Joseph, MI. Shannon, R. E. 1984. Artificial intelligence and simulation, Keynote Address. In. Proc. of Winter Simu. Conf. ed. S. Sheppard, U. Pooch, D. Pegden. Soc. for Comp. Simu., San Diego, CA. pp. 4-9. Shaw, L. G. and B. R. Gaines. 1987. A framework for knowledge-based systems unifying expert systems and simulation. In Intelligent simulation environment, ed. Paul Luker and H. Adelsberger. Soc. for Comp. Simu., San Diego, Simulation series, 17(1): 38-43. Shintani T. , Y. Katayama, K. Hiraishi and M. Toda. 1986. KORE-A hybrid knowledge programming environment for decision support based on a logic programming language. In: Lecture Notes in Computer Science, ed. G. Goos and J. Hartmanis, Logic Programming' 86, Proc. of the 5th Conf., Tokyo, Japan, pp. 22-32. Siemens, J. C, K. Hamburg and A. T. Tyrrell. 1988. Farm machinery selection program. ASAE Paper 88-1056. ASAE, St Joseph, MI. Slocombe, J. W. 1986. Agricultural mechanization curricula in 2000. ASAE Paper 86-5515. ASAE, St. Joseph, MI.
PAGE 233
222 Smith, R. D. 1985. Biomass storage, decision support systems and expert systems in crop production and processing. PhD thesis. Perdue University, West Lafayette, IN. Smith, R. D. , J. R. Barrett and R. M. Peart. 1985. Crop production management with expert systems. ASAE Paper 85-5521. ASAE St. Joseph, MI. Smith, O. R. , L. D. Gaultney, J. R. Barrett, D. D. Jones and C. H. Castore. 1988. Acceptability of expert systems by agricultural computer users. ASAE Paper 88-5023. ASAE St. Joseph, MI. Smith, R. D. , R. M. Peart and J. R. Barrett. 1985. Agricultural production management with decision support systems. ASAE Paper 85-3076. ASAE, St. Joseph, MI. Sowell, R. S., T. B. Bannett, D. W. Donahue and D. M. Crohn. 1888. Total farm machinery cost analysis with dBASE III and CLIPPER. ASAE Paper 88-1055. ASAE, St Joseph, MI. Stefik M. and D. G. Bobrow. 1986. Object-oriented programming: Themes and variations, AI Magazine, Winter 1986. pp. 40-59. Stone, N. D. , R. E. Frisbie, J. W. Richardson and R. N. Coulson. 1986. Integrated expert system applications for agriculture. Proc. of Int. Conf. on Computers in Agric. Ext. Prog., Feb. 1986. Orlando, FL. pp. 836-841 Thai, C. N. and C. P. Wilson. 1988. Simulation of peach post harvest operations. ASAE Paper 88-6058. ASAE, St. Joseph, MI. Thieme, R. H. , D. D. Jones and H. G. Gibson. 1986. A knowledge-based approach to forest road planning. ASAE Paper 86-1606. ASAE, St. Joseph, MI. Thieme, R. H. , J. W. Uhring, A. Dale Whittaker, R. M. Peart and J. R. Barrett. 1985. Grain marketing analysis with an expert system. ASAE Paper 85-5519. ASAE, St. Joseph, MI. Thomson, J. S. and R. M. Peart. 1986. An expert system for soil moisture-based scheduling of center pivot irrigation. ASAE Paper 86-4518. ASAE, St. Joseph, MI. Tsai, Y. J., J. W. Jones and J. W. Mishoe. 1987. Optimizing multiple cropping systems: A systems approach. Trans, of the ASAE 30(6) :1554-1561.
PAGE 234
223 Umphress, D. A. and U. W. Pooch. 1987. A goal oriented approach to simulation. In: Methodology and validation, ed. Osman Balsci. Soc. for Comp. Simu. , San Diego, CA. Simulation Series 19(l):44-49. Von Bargen K. and J. Hines. 1973. Economic Analysis of a complement of farm machines. ASAE paper 73-1529. ASAE, St. Joseph, MI. Von Bargen K. and R. M. Peart. 1969. Simulation of field machine and transport activities for a row crop planting system. ASAE Paper 69-657. ASAE, St. Joseph, MI. Walker A., M. McCord, J. F. Sowa and W. G. Wilson. 1987. Knowledge systems and prolog; Chapter 1; Knowledge systems: Principles and practices, Addision-Wesley Publishing Co. Inc., Reading, Massachusetts. pp. 1-22. Walton, T. F. 1967. Communications and data management. A Wiley-Interscience Publication. John Willey & Sons, New York, NY. Waterman, D. A. 1986. A guide to expert systems. AddisonWesley Publishing Co. Inc., Reading, MA. Waund, D. and L. Mundell. 1968. Linear programming model for a vegetable processor. Conf . Proceedings: Computers and Farm Machinery Management, Dec, 1968. ASAE, St. Joseph, MI. Webster, N. 1979. Webster's new twentieth century dictionary of the English language. Second edition. Simon and Schuster, New York, NY. Whittaker, D. A., E. J. Monke and F. R. Foster. 1987. ADAM: An ADaptive Assembler of Models. ASAE paper 87-5536. ASAE St. Joseph, MI. Wildberger A. M. 1988a. Selection of tools for including expert system components in simulations. Paper presented at the 1988 Summer Comp. Simu. Conf., July 1988. Seattle, WA. Wildberger A. M. 1988b. Integrating an expert systems component into a simulation. In. AI Papers, ed. Ranjeet J. Uttamsingh. Soc. for Comp. Simu., San Diego, CA. Simulation Series. 20 (1) : 132-135. Williamson, M. 1985. Artificial intelligence for microcomputers: The guide for business decision makers. Brady Communication Co. Inc., A Simon and Schuster Publishing Co. , New York, NY.
PAGE 235
224 Yokoi S. 1986. A PROLOG based object-oriented language and its compiler. In: Lecture Notes in Computer Science, ed. G. Goos and J. Hartmanis, Logic Programming' 86. Proc. of the 5th Conf. Tokyo, Japan. Yost, R. 1985. Expert system to develop and transfer soil management research. Annual Report and Work Plan. TROPSOIL. Management Entity, Raligh, NC.
PAGE 236
BIOGRAPHICAL SKETCH HARBANS LAL was born on Jan. 6, 1949, in Kashipur (UP) a small town in the Tarai region of northern India. He had his secondary education in New Delhi and attended Indian Institute of Technology (IIT) , Kharagpur, WB for his Bachelor and Master degrees in agricultural engineering from 1966 to 1973. He specialized in farm machinery and power as a major in agricultural engineering. After graduation from IIT, he worked as a full-time volunteer with the Front for Rapid Economics Advancement (FREA) , India to organize and manage an agro-service center to its Patoda base self-supporting. In 1974, he joined the International Crops Research Institute for the Semi-Arid Tropics (ICRISAT) , India, where he had the opportunity to work with professionals from different part of the world. As an Agricultural Engineer of the Farming Systems Research Team of the ICRISAT, he designed and developed agricultural implements for the improved farming systems developed at the ICRISAT. The adaptation of a traditional bullock cart to a animal-drawn tool carrier made such a technology within the economic reach of Indian farming community. 225
PAGE 237
226 He then moved to Brazil in 1979 to work for the Interamerican Institute of Agricultural Science (IICA) as a Mechanization Specialist. He was stationed at the Center of Agricultural Research for the Semi-Arid Tropics (CPATSA) of the Brazilian Enterprise for Agricultural Research (EMBRAPA) and had the responsibility to organize and conduct mechanization program. The W-shaped soil management system, developed as a part of his research efforts, provided a tillage technique to stabilize and increase the production of arid northeast Brazil and other similar regions of the world. His research has resulted in over 20 publications in refereed journals from different parts of the world. The desire to upgrade his qualifications and to learn modern techniques in agricultural engineering brought him back to school in 1986 for his Ph.D. The University of Florida (UF) was the choice because of its location in a tropical climate and a flexible curriculum in the Agricultural Engineering Department and a strong program in systems research. At UF, he concentrated in system engineering, learned about AI and simulation techniques and applied them to farm systems as demonstrated in this dissertation. He is married with Chitra and has three daughters Bhawna, Monika and Prerna. He plans to find employment where he can enhance his recently acquired understanding about knowledge and systems engineering and make use of his past experience.
PAGE 238
I certify that I have read this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. Dr. R. M. Peart, Chairman Graduate Research Professor of Agricultural Engineering I certify that I have read this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. Dr. W. D. Shoupf, Cochairman Professor of Agricultural Engineering I certify that I have read this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. rotessor of Agricultural Engineering I certify that I have read this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. Drr^Peter Hildebrand ^-— . Professor of Food and Resource Economics
PAGE 239
I certify that I have raad this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. Dr .'^Douglas D. Dankel Assistant Professor of Computer and Information Sciences This dissertation was submitted to the Graduate Faculty of the College of Engineering and to the Graduate School and was accepted as partial fulfillment of the requirements for the degree of Doctor of Philosophy. December 1989 Dean, Graduate School
PAGE 240
r, 'if^ n Q^
|
