• TABLE OF CONTENTS
HIDE
 Title Page
 Dedication
 Acknowledgement
 Table of Contents
 Abstract
 Introduction
 Review of literature
 System design and implementati...
 Testing and evaluation
 Conclusions and recommendation...
 Appendices
 References
 Biographical sketch






Title: Engineering farm knowledge for a seamless decision support system
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00097393/00001
 Material Information
Title: Engineering farm knowledge for a seamless decision support system
Physical Description: x, 226 leaves : ill. ; 28 cm.
Language: English
Creator: Lal, Harbans, 1949-
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 1989
Copyright Date: 1989
 Subjects
Subject: FARMSYS (Computer system)   ( lcsh )
Agriculture -- Data processing   ( lcsh )
Expert systems (Computer science)   ( lcsh )
Agricultural Engineering thesis Ph. D
Dissertations, Academic -- Agricultural Engineering -- UF
Genre: bibliography   ( marcgt )
non-fiction   ( marcgt )
 Notes
Thesis: Thesis (Ph. D.)--University of Florida, 1989.
Bibliography: Includes bibliographical references (leaves 212-224)
Additional Physical Form: Also available on World Wide Web
General Note: Typescript.
General Note: Vita.
Statement of Responsibility: by Harbans Lal.
 Record Information
Bibliographic ID: UF00097393
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: alephbibnum - 001531210
oclc - 22327369
notis - AHE4606

Downloads

This item has the following downloads:

PDF ( 7 MBs ) ( PDF )


Table of Contents
    Title Page
        Page i
        Page i-a
        Page ii
    Dedication
        Page iii
    Acknowledgement
        Page iv
        Page v
    Table of Contents
        Page vi
        Page vii
    Abstract
        Page viii
        Page ix
        Page x
    Introduction
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
    Review of literature
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
        Page 29
        Page 30
        Page 31
        Page 32
    System design and implementation
        Page 33
        Page 34
        Page 35
        Page 36
        Page 37
        Page 38
        Page 39
        Page 40
        Page 41
        Page 42
        Page 43
        Page 44
        Page 45
        Page 46
        Page 47
        Page 48
        Page 49
        Page 50
        Page 51
        Page 52
        Page 53
        Page 54
        Page 55
        Page 56
        Page 57
        Page 58
        Page 59
        Page 60
        Page 61
        Page 62
        Page 63
        Page 64
        Page 65
        Page 66
        Page 67
        Page 68
        Page 69
        Page 70
        Page 71
        Page 72
        Page 73
        Page 74
        Page 75
        Page 76
        Page 77
        Page 78
        Page 79
        Page 80
        Page 81
        Page 82
        Page 83
        Page 84
        Page 85
        Page 86
        Page 87
        Page 88
        Page 89
        Page 90
        Page 91
        Page 92
        Page 93
        Page 94
        Page 95
        Page 96
        Page 97
        Page 98
        Page 99
        Page 100
        Page 101
        Page 102
        Page 103
        Page 104
        Page 105
        Page 106
        Page 107
        Page 108
        Page 109
        Page 110
        Page 111
        Page 112
        Page 113
        Page 114
        Page 115
        Page 116
        Page 117
        Page 118
        Page 119
        Page 120
        Page 121
        Page 122
        Page 123
        Page 124
        Page 125
        Page 126
        Page 127
        Page 128
        Page 129
    Testing and evaluation
        Page 130
        Page 131
        Page 132
        Page 133
        Page 134
        Page 135
        Page 136
        Page 137
        Page 138
        Page 139
        Page 140
        Page 141
        Page 142
        Page 143
        Page 144
        Page 145
        Page 146
        Page 147
        Page 148
        Page 149
        Page 150
        Page 151
        Page 152
        Page 153
        Page 154
        Page 155
        Page 156
        Page 157
        Page 158
        Page 159
        Page 160
        Page 161
        Page 162
        Page 163
        Page 164
        Page 165
        Page 166
        Page 167
        Page 168
        Page 169
        Page 170
        Page 171
        Page 172
        Page 173
        Page 174
        Page 175
        Page 176
        Page 177
        Page 178
        Page 179
        Page 180
        Page 181
        Page 182
        Page 183
        Page 184
        Page 185
    Conclusions and recommendations
        Page 186
        Page 187
        Page 188
        Page 189
        Page 190
        Page 191
    Appendices
        Page 192
        Page 193
        Page 194
        Page 195
        Page 196
        Page 197
        Page 198
        Page 199
        Page 200
        Page 201
        Page 202
        Page 203
        Page 204
        Page 205
        Page 206
        Page 207
        Page 208
        Page 209
        Page 210
        Page 211
    References
        Page 212
        Page 213
        Page 214
        Page 215
        Page 216
        Page 217
        Page 218
        Page 219
        Page 220
        Page 221
        Page 222
        Page 223
        Page 224
    Biographical sketch
        Page 225
        Page 226
        Page 227
        Page 228
        Page 229
Full Text













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




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs