Citation
Engineering farm knowledge for a seamless decision support system

Material Information

Title:
Engineering farm knowledge for a seamless decision support system
Creator:
Lal, Harbans, 1949- ( Dissertant )
Peart, R. M. ( Thesis advisor )
Shoup, W. D. ( Thesis advisor )
Jones, J. W. ( Reviewer )
Hildebrand, Peter ( Reviewer )
Dankel, Douglas D. ( Reviewer )
Place of Publication:
Gainesville, Fla.
Publisher:
University of Florida
Publication Date:
Copyright Date:
1989
Language:
English
Physical Description:
x, 226 leaves : ill. ; 28 cm.

Subjects

Subjects / Keywords:
Cotton ( jstor )
Crops ( jstor )
Farming ( jstor )
Farms ( jstor )
Horticultural practices ( jstor )
Modeling ( jstor )
Planting ( jstor )
Simulations ( jstor )
Tractors ( jstor )
Work hours ( jstor )
Agricultural Engineering thesis Ph. D
Agriculture -- Data processing ( lcsh )
Dissertations, Academic -- Agricultural Engineering -- UF
Expert systems (Computer science) ( lcsh )
FARMSYS (Computer system) ( lcsh )
City of Gainesville ( local )
Genre:
bibliography ( marcgt )
theses ( marcgt )
non-fiction ( marcgt )

Notes

Abstract:
Farm operational knowledge including dynamic processes as well as heuristics for expert planning and management for machinery, labor and other resources has been represented and manipulated utilizing knowledge engineering concepts of artificial intelligence (AI) in logic programming (PROLOG) . The new approach permitted integration of simulation, expert systems and databases under one single environment, thus leading to a seamless decision support system. It also enabled imparting some of the "intelligent" functions of simulation processes, generally performed by human experts, to computers, thus facilitating their usage by non-experts. A decision support system (FARMSYS) with four components, namely, object-oriented simulation, logic-based expert system. knowledge-based yield estimation system and intelligent information system, has been designed, constructed and evaluated. A team of experts evaluated professional qualifications of FARMSYS and found its structure excellent with a comprehensive framework for a variety of applications. All its components functioned correctly, intelligently, and in harmony with one another, using knowledge from an operational farm in north Florida. The Operations Simulator successfully simulated field operations for complete cropping season and responded correctly to scheduled work hours and to the withdrawal of machinery and laborer. The Expert Analysis component successfully imitated the behavior of machinery management expert (s) . Its recommendations and other support were effective, and demonstrated the possibility of reducing the machinery and labor force from the test farm without significantly affecting the timeliness of the majority of farm operations. The Yield Estimation system responded to different work hours during critical operations showing their effects on crop yields and profits. The Information Management System expedited the development and updating process of the farm knowledge-bases to carry out different tests with FARMSYS, thus demonstrating its successful functioning as an integrated decision support system. PROLOG facilitated simulating field operations in an object-oriented manner, a new AI method of programming. Its 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 modeling of aspects of the system that are typically ignored or difficult to model when using conventional approaches.
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

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright [name of dissertation author]. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Resource Identifier:
021530940 ( alephbibnum )
22327369 ( oclc )
AHE4606 ( notis )

Downloads

This item has the following downloads:

PDF ( 7 MBs ) ( .pdf )

engineeringfarmk00lalhrich_Page_233.txt

engineeringfarmk00lalhrich_Page_021.txt

engineeringfarmk00lalhrich_Page_181.txt

engineeringfarmk00lalhrich_Page_190.txt

engineeringfarmk00lalhrich_Page_053.txt

engineeringfarmk00lalhrich_Page_123.txt

engineeringfarmk00lalhrich_Page_207.txt

engineeringfarmk00lalhrich_Page_001.txt

engineeringfarmk00lalhrich_Page_010.txt

engineeringfarmk00lalhrich_Page_135.txt

engineeringfarmk00lalhrich_Page_086.txt

engineeringfarmk00lalhrich_Page_045.txt

engineeringfarmk00lalhrich_Page_063.txt

engineeringfarmk00lalhrich_Page_064.txt

engineeringfarmk00lalhrich_Page_049.txt

engineeringfarmk00lalhrich_Page_051.txt

engineeringfarmk00lalhrich_Page_019.txt

engineeringfarmk00lalhrich_Page_204.txt

engineeringfarmk00lalhrich_Page_075.txt

engineeringfarmk00lalhrich_Page_187.txt

engineeringfarmk00lalhrich_Page_098.txt

engineeringfarmk00lalhrich_Page_220.txt

engineeringfarmk00lalhrich_Page_072.txt

engineeringfarmk00lalhrich_Page_173.txt

engineeringfarmk00lalhrich_Page_105.txt

engineeringfarmk00lalhrich_Page_239.txt

engineeringfarmk00lalhrich_Page_230.txt

engineeringfarmk00lalhrich_Page_044.txt

engineeringfarmk00lalhrich_Page_023.txt

engineeringfarmk00lalhrich_Page_048.txt

engineeringfarmk00lalhrich_Page_161.txt

engineeringfarmk00lalhrich_Page_138.txt

engineeringfarmk00lalhrich_Page_085.txt

engineeringfarmk00lalhrich_Page_150.txt

engineeringfarmk00lalhrich_Page_122.txt

engineeringfarmk00lalhrich_Page_168.txt

engineeringfarmk00lalhrich_Page_130.txt

engineeringfarmk00lalhrich_Page_182.txt

engineeringfarmk00lalhrich_Page_227.txt

engineeringfarmk00lalhrich_Page_009.txt

engineeringfarmk00lalhrich_Page_136.txt

engineeringfarmk00lalhrich_Page_193.txt

engineeringfarmk00lalhrich_Page_205.txt

engineeringfarmk00lalhrich_Page_096.txt

engineeringfarmk00lalhrich_Page_101.txt

engineeringfarmk00lalhrich_Page_114.txt

engineeringfarmk00lalhrich_Page_159.txt

engineeringfarmk00lalhrich_Page_094.txt

engineeringfarmk00lalhrich_Page_189.txt

engineeringfarmk00lalhrich_Page_120.txt

engineeringfarmk00lalhrich_Page_184.txt

engineeringfarmk00lalhrich_Page_169.txt

engineeringfarmk00lalhrich_Page_043.txt

engineeringfarmk00lalhrich_Page_125.txt

engineeringfarmk00lalhrich_Page_030.txt

engineeringfarmk00lalhrich_Page_003.txt

engineeringfarmk00lalhrich_Page_065.txt

engineeringfarmk00lalhrich_Page_013.txt

engineeringfarmk00lalhrich_Page_127.txt

engineeringfarmk00lalhrich_Page_060.txt

engineeringfarmk00lalhrich_Page_031.txt

engineeringfarmk00lalhrich_Page_158.txt

engineeringfarmk00lalhrich_Page_007.txt

engineeringfarmk00lalhrich_Page_111.txt

engineeringfarmk00lalhrich_Page_171.txt

engineeringfarmk00lalhrich_Page_185.txt

engineeringfarmk00lalhrich_Page_076.txt

engineeringfarmk00lalhrich_Page_160.txt

engineeringfarmk00lalhrich_Page_223.txt

engineeringfarmk00lalhrich_Page_238.txt

engineeringfarmk00lalhrich_Page_097.txt

engineeringfarmk00lalhrich_Page_016.txt

engineeringfarmk00lalhrich_Page_145.txt

engineeringfarmk00lalhrich_Page_170.txt

engineeringfarmk00lalhrich_Page_177.txt

engineeringfarmk00lalhrich_Page_054.txt

engineeringfarmk00lalhrich_Page_015.txt

engineeringfarmk00lalhrich_Page_040.txt

engineeringfarmk00lalhrich_Page_196.txt

engineeringfarmk00lalhrich_Page_074.txt

engineeringfarmk00lalhrich_Page_104.txt

engineeringfarmk00lalhrich_Page_217.txt

engineeringfarmk00lalhrich_Page_208.txt

engineeringfarmk00lalhrich_Page_192.txt

engineeringfarmk00lalhrich_Page_151.txt

engineeringfarmk00lalhrich_Page_115.txt

engineeringfarmk00lalhrich_Page_034.txt

engineeringfarmk00lalhrich_Page_172.txt

engineeringfarmk00lalhrich_Page_165.txt

engineeringfarmk00lalhrich_Page_235.txt

engineeringfarmk00lalhrich_Page_219.txt

engineeringfarmk00lalhrich_Page_052.txt

engineeringfarmk00lalhrich_Page_163.txt

engineeringfarmk00lalhrich_Page_149.txt

engineeringfarmk00lalhrich_Page_106.txt

engineeringfarmk00lalhrich_Page_012.txt

engineeringfarmk00lalhrich_Page_155.txt

engineeringfarmk00lalhrich_pdf.txt

engineeringfarmk00lalhrich_Page_039.txt

engineeringfarmk00lalhrich_Page_011.txt

engineeringfarmk00lalhrich_Page_166.txt

engineeringfarmk00lalhrich_Page_005.txt

engineeringfarmk00lalhrich_Page_202.txt

engineeringfarmk00lalhrich_Page_047.txt

engineeringfarmk00lalhrich_Page_157.txt

engineeringfarmk00lalhrich_Page_058.txt

engineeringfarmk00lalhrich_Page_179.txt

engineeringfarmk00lalhrich_Page_008.txt

engineeringfarmk00lalhrich_Page_004.txt

engineeringfarmk00lalhrich_Page_036.txt

engineeringfarmk00lalhrich_Page_056.txt

engineeringfarmk00lalhrich_Page_174.txt

engineeringfarmk00lalhrich_Page_213.txt

engineeringfarmk00lalhrich_Page_131.txt

engineeringfarmk00lalhrich_Page_226.txt

engineeringfarmk00lalhrich_Page_059.txt

engineeringfarmk00lalhrich_Page_006.txt

engineeringfarmk00lalhrich_Page_195.txt

engineeringfarmk00lalhrich_Page_027.txt

engineeringfarmk00lalhrich_Page_134.txt

engineeringfarmk00lalhrich_Page_232.txt

engineeringfarmk00lalhrich_Page_162.txt

engineeringfarmk00lalhrich_Page_067.txt

engineeringfarmk00lalhrich_Page_178.txt

engineeringfarmk00lalhrich_Page_029.txt

engineeringfarmk00lalhrich_Page_117.txt

engineeringfarmk00lalhrich_Page_038.txt

engineeringfarmk00lalhrich_Page_152.txt

engineeringfarmk00lalhrich_Page_210.txt

engineeringfarmk00lalhrich_Page_137.txt

engineeringfarmk00lalhrich_Page_176.txt

engineeringfarmk00lalhrich_Page_231.txt

engineeringfarmk00lalhrich_Page_062.txt

engineeringfarmk00lalhrich_Page_167.txt

engineeringfarmk00lalhrich_Page_144.txt

engineeringfarmk00lalhrich_Page_112.txt

engineeringfarmk00lalhrich_Page_218.txt

engineeringfarmk00lalhrich_Page_237.txt

engineeringfarmk00lalhrich_Page_079.txt

engineeringfarmk00lalhrich_Page_077.txt

engineeringfarmk00lalhrich_Page_201.txt

engineeringfarmk00lalhrich_Page_017.txt

engineeringfarmk00lalhrich_Page_100.txt

engineeringfarmk00lalhrich_Page_046.txt

engineeringfarmk00lalhrich_Page_229.txt

engineeringfarmk00lalhrich_Page_088.txt

engineeringfarmk00lalhrich_Page_014.txt

engineeringfarmk00lalhrich_Page_026.txt

engineeringfarmk00lalhrich_Page_020.txt

engineeringfarmk00lalhrich_Page_222.txt

engineeringfarmk00lalhrich_Page_107.txt

engineeringfarmk00lalhrich_Page_024.txt

engineeringfarmk00lalhrich_Page_191.txt

engineeringfarmk00lalhrich_Page_118.txt

engineeringfarmk00lalhrich_Page_175.txt

engineeringfarmk00lalhrich_Page_129.txt

engineeringfarmk00lalhrich_Page_146.txt

engineeringfarmk00lalhrich_Page_083.txt

engineeringfarmk00lalhrich_Page_071.txt

engineeringfarmk00lalhrich_Page_109.txt

engineeringfarmk00lalhrich_Page_147.txt

engineeringfarmk00lalhrich_Page_069.txt

engineeringfarmk00lalhrich_Page_188.txt

engineeringfarmk00lalhrich_Page_211.txt

engineeringfarmk00lalhrich_Page_199.txt

engineeringfarmk00lalhrich_Page_164.txt

engineeringfarmk00lalhrich_Page_156.txt

engineeringfarmk00lalhrich_Page_128.txt

engineeringfarmk00lalhrich_Page_148.txt

engineeringfarmk00lalhrich_Page_143.txt

engineeringfarmk00lalhrich_Page_042.txt

engineeringfarmk00lalhrich_Page_139.txt

engineeringfarmk00lalhrich_Page_087.txt

engineeringfarmk00lalhrich_Page_082.txt

engineeringfarmk00lalhrich_Page_153.txt

engineeringfarmk00lalhrich_Page_103.txt

engineeringfarmk00lalhrich_Page_154.txt

engineeringfarmk00lalhrich_Page_209.txt

engineeringfarmk00lalhrich_Page_099.txt

engineeringfarmk00lalhrich_Page_133.txt

engineeringfarmk00lalhrich_Page_102.txt

engineeringfarmk00lalhrich_Page_078.txt

engineeringfarmk00lalhrich_Page_124.txt

engineeringfarmk00lalhrich_Page_198.txt

engineeringfarmk00lalhrich_Page_032.txt

engineeringfarmk00lalhrich_Page_126.txt

engineeringfarmk00lalhrich_Page_080.txt

engineeringfarmk00lalhrich_Page_113.txt

engineeringfarmk00lalhrich_Page_061.txt

engineeringfarmk00lalhrich_Page_070.txt

engineeringfarmk00lalhrich_Page_203.txt

engineeringfarmk00lalhrich_Page_119.txt

engineeringfarmk00lalhrich_Page_183.txt

engineeringfarmk00lalhrich_Page_121.txt

engineeringfarmk00lalhrich_Page_215.txt

engineeringfarmk00lalhrich_Page_090.txt

engineeringfarmk00lalhrich_Page_142.txt

engineeringfarmk00lalhrich_Page_018.txt

engineeringfarmk00lalhrich_Page_108.txt

engineeringfarmk00lalhrich_Page_035.txt

engineeringfarmk00lalhrich_Page_073.txt

engineeringfarmk00lalhrich_Page_081.txt

engineeringfarmk00lalhrich_Page_200.txt

engineeringfarmk00lalhrich_Page_037.txt

engineeringfarmk00lalhrich_Page_093.txt

engineeringfarmk00lalhrich_Page_141.txt

engineeringfarmk00lalhrich_Page_116.txt

engineeringfarmk00lalhrich_Page_214.txt

engineeringfarmk00lalhrich_Page_025.txt

engineeringfarmk00lalhrich_Page_225.txt

engineeringfarmk00lalhrich_Page_095.txt

engineeringfarmk00lalhrich_Page_186.txt

engineeringfarmk00lalhrich_Page_033.txt

engineeringfarmk00lalhrich_Page_212.txt

engineeringfarmk00lalhrich_Page_089.txt

engineeringfarmk00lalhrich_Page_228.txt

engineeringfarmk00lalhrich_Page_110.txt

engineeringfarmk00lalhrich_Page_140.txt

engineeringfarmk00lalhrich_Page_055.txt

engineeringfarmk00lalhrich_Page_221.txt

engineeringfarmk00lalhrich_Page_236.txt

engineeringfarmk00lalhrich_Page_066.txt

engineeringfarmk00lalhrich_Page_041.txt

engineeringfarmk00lalhrich_Page_028.txt

engineeringfarmk00lalhrich_Page_224.txt

engineeringfarmk00lalhrich_Page_091.txt

engineeringfarmk00lalhrich_Page_022.txt

engineeringfarmk00lalhrich_Page_068.txt

engineeringfarmk00lalhrich_Page_132.txt

engineeringfarmk00lalhrich_Page_206.txt

engineeringfarmk00lalhrich_Page_234.txt

engineeringfarmk00lalhrich_Page_197.txt

engineeringfarmk00lalhrich_Page_084.txt

engineeringfarmk00lalhrich_Page_092.txt

engineeringfarmk00lalhrich_Page_194.txt

engineeringfarmk00lalhrich_Page_057.txt

engineeringfarmk00lalhrich_Page_180.txt

engineeringfarmk00lalhrich_Page_050.txt

engineeringfarmk00lalhrich_Page_216.txt


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




Full Text

PAGE 1

ENGINEERING FARM KNOWLEDGE FOR A SEAMLESS DECISION SUPPORT SYSTEM BY HARBANS LAL A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 1989

PAGE 2

UNIVERSITY OF FLORIDA llliillil 3 1262 08552 3453

PAGE 3

Copyright 1989 by Harbans Lai

PAGE 4

Dedicated to the Fanning Community of the World

PAGE 5

ACKNOWLEDGEMENTS I would like to express my deep hearted gratitude to Dr. R. M. Peart, Graduate Research Professor of Agricultural Engineering, for serving as a chairman for my dissertation work. The efforts of Dr. W. D. Shoup of the Department of Agricultural Engineering in formalizing the project and serving as cochairman on my supervisory committee are highly appreciated. The financial support for the studies and the dissertation was provided by International Benchmark Sites for Agrotechnology Transfer (IBSNAT) . Dr. J. W. Jones, also from Agricultural Engineering Department, played a key role in arranging this support and helping me in structuring and conceptualizing different aspects of the dissertation. I specially thank him for his efforts and guidance. I would also like to thank Dr. Peter Hildebrand from the Food and Resource Economics Department and Dr. D. Dankel from the Department of Computer and Information Sciences, who provided a unique blend of expertise in farming systems and knowledgebased systems needed for the dissertation. Mr. Jerry Davis and his wife from Santa Rosa County in North Florida provided the details about their farm setting for operational verification of the dissertation work. They IV

PAGE 6

deserve my special thanks for sparing their time and valuable information. I also thank all participants of the miniconference on Knowledge-based Decision Systems using Logic Programming who spared time from their busy schedule to come to Gainesville and help us evaluate and qualify FARMSYS. The patience and moral support of my wife Chitra, who kept my morale high all through the study period, deserves special appreciation. I would also like to thank my three daughters Bhawana, Monika and Prerna who found their dad busy with his studies whenever they wanted him to play with them. I would also like to register my thanks for Dr. P. N. Sharma, my friend and my old time college and professional colleague, who inspired me to return to school after a professional career of 13 years. Last but not the least, I would like to acknowledge the efforts of my parents, brothers and sisters whose hard work constituted the foundation work for my higher studies and ultimately this dissertation.

PAGE 7

TABLE OF CONTENTS pages ACKNOWLEDGEMENTS iv ABSTRACT viii CHAPTER I INTRODUCTION 1 Justification 1 Ob j ectives 4 II REVIEW OF LITERATURE 7 Conventional Decision-aid Tools 7 Machinery Management Applications 9 Limitations 14 Knowledge Engineering Concepts and Applications 16 Knowledge Classification 17 Knowledge-Based Decision Systems 18 Applications 27 III SYSTEM DESIGN AND IMPLEMENTATION 33 Object-Oriented Simulation 37 Farm as a System 40 Knowledge Representation 46 Model Description 47 Simulation in PROLOG 53 Expert Simulation Analysis 65 Operations Analysis Report 69 Machinery Usage Report 83 Accumulated Work Report 90 Knowledge-Based Yield Estimation 93 Crop Yield Knowledge-Bases 95 Expert Search System 97 An Intelligent Information Management System. . . 102 Characteristics 108 Components and their Functions 109 Knowledge-Bases Utilized and Generated 114 VI

PAGE 8

pages IV TESTING AND EVALUATION 130 Professional Qualification 131 Structured Response Analysis 142 Non-Structured Responses 144 Role of Mini-Conference in Evaluating Knowledge-based Systems 145 Operational Level Verification 14 6 Description of the Test Farm 148 Setting up Farm Knowledge for Simulation Runs 148 Operations Simulation Reports 153 Expert Analysis System 161 Test Runs with FARMSYS 172 Yield Estimation System 180 Integrated Decision System 182 V CONCLUSIONS AND RECOMMENDATIONS 186 APPENDICES I KNOWLEDGE-BASES 192 II MINI -CONFERENCE FOR FARMSYS QUALIFICATION 198 REFERENCES 212 BIOGRAPHICAL SKETCH 225 Vll

PAGE 9

Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy ENGINEERING FARM KNOWLEDGE FOR A SEAMLESS DECISION SUPPORT SYSTEM by HARBANS LAL December 1989 Chairman: Dr. R. M. Peart Major Department: Agricultural Engineering Farm operational knowledge including dynamic processes as well as heuristics for expert planning and management for machinery, labor and other resources has been represented and manipulated utilizing knowledge engineering concepts of artificial intelligence (AI) in logic programming (PROLOG) . The new approach permitted integration of simulation, expert systems and databases under one single environment, thus leading to a seamless decision support system. It also enabled imparting some of the "intelligent" functions of simulation processes, generally performed by human experts, to computers, thus facilitating their usage by non-experts. A decision support system (FARMSYS) with four components, namely, object-oriented simulation, logic-based expert system. • • « Vlll

PAGE 10

knowledge-based yield estimation system and intelligent information system, has been designed, constructed and evaluated. A team of experts evaluated professional qualifications of FARMSYS and found its structure excellent with a comprehensive framework for a variety of applications. All its components functioned correctly, intelligently, and in harmony with one another, using knowledge from an operational farm in north Florida. The Operations Simulator successfully simulated field operations for complete cropping season and responded correctly to scheduled work hours and to the withdrawal of machinery and laborer. The Expert Analysis component successfully imitated the behavior of machinery management expert (s) . Its recommendations and other support were effective, and demonstrated the possibility of reducing the machinery and labor force from the test farm without significantly affecting the timeliness of the majority of farm operations. The Yield Estimation system responded to different work hours during critical operations showing their effects on crop yields and profits. The Information Management System expedited the development and updating process of the farm knowledge-bases to carry out different tests with FARMSYS, thus demonstrating its successful functioning as an integrated decision support system. PROLOG facilitated simulating field operations in an object-oriented manner, a new AI method of programming. Its ix

PAGE 11

inferencing capabilities have been utilized to incorporate several expert systems within and outside the simulation and other components of FARMSYS. The object-oriented approach allowed for the modelling of aspects of the system that are typically ignored or difficult to model when using conventional approaches.

PAGE 12

CHAPTER I INTRODUCTION Justification The stochastic nature of weather and complexity of other endogenous and exogenous factors responsible for crop production makes the job of the farmer much more complex and challenging in comparison to industrial production systems. Machinery and labor constitute a major component of capital outlay for crop production in an operational farm system. They control the operational behavior of the farm systems. Farmers are generally faced with the problem of selecting appropriate machinery (size and mix) , scheduling the correct amount of labor, deciding acreage for each crop along with its cropping calendar, and selecting methods for various operations (amount of tillage, number of cultivations, combining pesticide applications with other operations, etc.) . A number of farm-scale models have been developed to facilitate machinery and labor planning and management decision-making process by farmers under conflicting, complex and multiple choice situations. These models have been classified into six categories: linear programming models, simulation models, discount cash flow models, computerized budgeting models, machinery replacement models and machinery

PAGE 13

2 cost and utilization records (Nelson and Bowers, 1968) . Among all these categories, the simulation models capture the dynamic behavior of operational farm systems (Peart and Barrett, 1979) . The ability of these models to duplicate the real world system depends upon their formulation and incorporation of factors responsible for their control in as realistic manner as possible (Elderen, 1981; Elderen, 1987). The conventional approach to simulation is characterized as algorithmic or procedural. In this approach an algorithm or a procedure is first defined to solve the problem at hand. A computer program is then written using one of the procedural languages such as FORTRAN, BASIC or PASCAL to implement the algorithm. One of the major limitation of this approach of simulation is its inability to model intelligent behavior of the system. Often simple approximations are used instead. The path of activities that a customer takes in a service simulation (for example a simulation of the shop) is modelled by probabilities determined by prior observations and sampling, rather than by modelling the decision mechanism of the customer (O'Keefe and Roach, 1987) . In addition, the simulation does not provide solutions to the problems. It mainly shows the values of a set of variables over a period of time given certain assumptions. The interpretation of these values and drawing inferences from them lies beyond the scope and intent of the simulation program itself. Simulation cannot guide the user through the

PAGE 14

3 decision-making process of recommending appropriate managerial actions which could improve the productivity of the system. This is completely left to the user's capabilities and initiative. The results from simulation are often complex and remain within an exclusive domain of the experts for their interpretation. The scarcity and the cost of expert advice for output interpretation creates a serious bottleneck and can even nullify the advantages of simulation as a management and/or planning tool (Khuri et al., 1988). Knowledge-based decision systems are integrated packages which combine the capability of expert systems and simulation, including necessary data bases (Peart et al., 1985; Peart et al., 1988). They can intelligently apply analytical tools to deal with real world problems. They are developed using modern Artificial Intelligence (Al) languages such as PROLOG, LISP, SmallTalk or specialized development programs called shells. They have the capability of handling qualitative knowledge in addition to quantitative and procedural knowledge. The knowledge representation techniques of these languages can be utilized to maintain farm and regional knowledge separate from the computer code of the model, thus making them versatile and flexible. The inferencing capability of Al languages can allow for the modelling of aspects of the system that are typically ignored or are difficult to model when using conventional

PAGE 15

4 approach: for instance, adaptive behavior, where the activity attempted next is determined by some perception of the present state of the system (O'Keefe and Roach, 1987) . Simple decision rules (for instance, always join the shortest queue) , frequently inadequately captured in conventional simulation technique, can be better apprehended using AI techniques. It can also help incorporate expert systems as an integral component of the simulation to facilitate analysis and interpretation of their results. In recent years there have been some attempts in using the above approach for developing models for an operational farm decision support system. However, there is no reference in the literature to an agricultural expert decision system with simulation and databases that has been developed using a single programming environment. Objectives The general object is to represent and manipulate farm operational knowledge, including dynamic processes as well as heuristics for expert planning and management for machinery, labor and other resources utilizing knowledge engineering concepts of artificial intelligence. The specific objectives are as follows: 1) to construct a semantic representation of farm operational knowledge for crop production systems;

PAGE 16

5 2) to manipulate farm operational knowledge for simulating field operations for a complete cropping calendar using object-oriented approach; 3) to design and implement an expert analysis system to analyze the simulation results in the context of the farm knowledge to study labor and machinery utilization, and to develop appropriate recommendations for efficient planning and management of farm operations; 4) to develop a mechanism of utilizing crop growth simulation models and/or knowledge of regional crop experts for predicting crop yields in the context of farm knowledge and simulated dates of operations and 5) to integrate the simulation and expert knowledge into a decision-aid tool with an interactive user interface, and to verify its professional qualifications and operational capabilities as an expert planning tool for multi-crop production systems. The remainder of this dissertation is organized as four more chapters. The review of literature in Chapter II deals with the decision-aid tools developed utilizing algorithmic and procedural approaches, and concepts and applications of knowledge engineering in the field of agriculture. The design and implementation of the decision system consisting of an object-oriented field operations simulation, an expert analysis system of the simulation reports, a knowledge-based crop yield estimation and an intelligent

PAGE 17

6 information system are discussed in chapter III. This chapter also describes briefly how PROgramming in LOGic (PROLOG) has been utilized for writing the simulation, the first application of logic-based simulation in agriculture. Chapter IV reports the procedure and results of the evaluation and testing used to qualify FARMSYS as an integrated decision system for multi-crop production. The professional qualification of the system was carried out by letting a team of experts evaluate and critique the system, and the operational verification of its different components was conducted utilizing real farm data from north Florida. Finally, Chapter V presents conclusions and the recommendations for future work for farm-scale knowledge-based systems in general and FARMSYS in particular.

PAGE 18

CHAPTER II REVIEW OF LITERATURE Conventional Decision-aid Tools The crop production process can be described as a system of n-stage decision problems. These n-stages are differentiated by weather, the state of the crops and/or fields and availability of inputs, labor and machinery. At each decision-making moment the farmer selects some person and machine to perform certain operation (s) on fields and/or crops. They (the field and/or crop) have to be ready with appropriate soil moisture, ripeness, etc. to receive the services. The operation (s) on the fields are performed with available or selected labor and machines. The process transforms the current stage of the system into the next one with a new set of characteristics for the crop(s) and the field (s) . This new state then becomes the next challenge for the farmer to make a decision and this process goes on until all the tasks of the production process are terminated. The stochastic nature of the weather and complexity of other factors responsible for crop production, both endogenous and exogenous, makes the job of the farmer much more complex and challenging in comparison to other industrial production

PAGE 19

8 systems. Farmers are always concerned about appropriate selection, efficient utilization and management of the resources at their disposal in order to have better control over the production process at different problem stages. Agricultural scientists have been developing computer models to facilitate the decision-making process by farmers under conflicting, complex and multiple-choice situations (Jones et al., 1988; Tsai et al., 1987; Chen and McClendon, 1985) . These models, both analytical and simulation, can be broadly classified into 1) plant-scale models, 2) field-scale models and 3) farm-scale models. The plant-scale models study the behavior of individual plant and extrapolate the results for the whole field. Examples of such models are the crop growth simulation models (Jones et al., 1988) designed to study the physiological development and growth of plants. These models have been commonly used to better understand the development process of the plant. However, in recent years there have been some attempts to use them as decision-aid tools (Boggess and Amerling, 1983; Boote and Jones, 1986; Hoogenboom et al., 1987; Meyer and Curry, 1986). The field-scale models study the behavior of an individual field in terms of its adaptability to different cropping systems for its environmental and soil characteristics. These models generally do not consider the operational constraints (machinery and labor requirements) to

PAGE 20

9 implement the candidate or the selected cropping systems (Tsai et al. , 1987) . The farm-scale models capture the behavior of the farm as a whole. They consider the operational constraints of the farm and can help farmers make strategic planning and/or tactical management decisions. Both quantitative techniques such as linear programming and simulation, and analytical mathematical models have been used to develop such models. All three types of models, discussed above, are important in developing decision-aid tools for a farm setting. They should be considered as complementary rather than competitor or substitutes for one another. The plant-based models should serve as the basic tools for developing field-scale models. The field scale models can then serve as a starting point for farm-scale models. Machinery Management Applications The machinery and labor constitute a major component of capital outlay in an operational farm system. In addition to climatic and soil factors on which farmer has little or no direct control, the machinery and labor control the operational behavior of a farm system. Therefore, a large number of farm-scale models have been developed to deal with machinery and labor management aspects of farming operations. These models serve as decision-aid tools for selecting an appropriate mix for the machinery set, scheduling various

PAGE 21

10 field operations, and estimating the cost of owning and operating these machinery sets for a given farm setting. The six categories of these types of models, namely linear programming, simulation models, discount cash flow models, computerized budgeting models, machinery replacement models and machinery cost and utilization records (Nelson and Bowers, 1968) , can be broadly divided into two groups: 1) the analytical models and 2) the simulation models. Analytical models are designed mainly for selecting and pricing the machinery operations based upon the given cropping calendars, cost of timeliness and other related factors. Most of these models employ similar algorithms in selecting and scheduling the machinery for different operations. They first estimate available times (hours) to complete each operation based upon available workable days and number of work hours per working day. The models then estimate actual times (hours) needed for each operation based upon machinery capacity. The actual working times are added to the beginning times of different operations to determine their completion times. The actual start and finish times for critical operations such as planting and harvesting are utilized to estimate timeliness cost (Hetz & Esmay, undated; Burrows and Siemens, 1974; Ozkan and Edwards, 1986a; Sowell et al., 1988; Gui and Siemens, 1986; Siemens et al., 1988). Some researchers have utilized this algorithm in a reverse order to estimate the

PAGE 22

11 machinery size to complete the operation within optimum time period (Edwards and Michael, 1980; Ozkan et al., 1984; Chen, 1986; Siemens et al., 1988). In all these applications, the machinery and labor time, and timeliness of operations are converted in economic terms to estimate the net returns from crop production activity by using different machinery sets. In addition, some researchers have developed software for estimating machinery capacities and their cost of operations with no consideration to timeliness factors (Ozkan and Edwards, 1986a; Lai and Frerie, 1984) . There is a wide variation in application of simulation techniques for machinery management related problems. It ranges from simulating one single operation for one crop to simulating complete growing season with mono-crop or multicrop. The single operation models have mainly been developed for harvesting operations. Glunz (1985) and Thai and Wilson (1988) used discrete event simulation approach (Pritsker and Pegden, 1979) for simulating harvesting operations for citrus and peaches, respectively. On the other hand, Miles and Tsai (1987) and Labiadh and Frisby (1987) used a discrete processoriented approach for simulating grain and hay harvesting operations. The models for a complete cropping season for a farm setting have been developed using the activity network technique (Link and Bockhop, 1964; Link, 1967; Von Bargen and

PAGE 23

12 Peart, 1969), linear programming technique (Nagarajan et al., 1985; Bender, 1984; Candler, 1968; Waund and Mundell, 1968; Geyer et al., 1963), simulation approach (Tsai et al., 1987; Chen and McClendon, 1985; Smith, 1985) and database management concept (Gauthier and Kok, 1988) . Activity network analysis In this approach the complete production system is represented as a set of activities and events which are then analyzed using standard operations research techniques such as PERT (Project Evaluation and Review Technique) or CPM (Critical Path Method) as explained by Link (1967) . The preference for one activity over another in case of a conflicting situations and overlapping of timings for different activities are some of the factors for which it is difficult to account in this approach of simulation. Linear programming approach In this approach the n-stages of crop production are represented by n-periods during which available time is allocated to different activities to attain an optimum allocation strategy. In this case the problem is solved using a procedure (simplex algorithm) which optimizes the solution by considering all the periods simultaneously. But the stages in crop production are sequential, dynamic and interdependent. This means that decisions at each stage would depend upon what

PAGE 24

13 was achieved during earlier stage (s) . In addition, the basic assumptions such as 1) additivity of resources and activities, 2) linearity of objective function, 3) divisibility of resources and activities, and 4) single valued expectations of the linear program restrict its capability in modelling whole farm systems accurately. In addition, the linear programming technique has to use an average weather year and other values of operational coefficients. It cannot account for nonlinear effects of bad weather, for example. Integer Programming (Brown, 1974) and integration of linear programming with simulation (Bender, 1984; Konaka, 1987) are some of the approaches which have been tried to overcome the limitations of the linear programming approach. Simulation model Simulation has been utilized to study both continuous and discrete systems. Continuous systems are characterized by smooth uninterrupted changes in their state variables. The rates of the state variables in such systems are represented by differential or difference equations. In case of discrete systems, the state of the system changes in distinct stages, such as queuing models (Pritsker, 1984) . There exists great a variation among different farm scale simulation models in terms of their approaches to development. Tsai et al., 1987 used a systems approach for optimizing multiple cropping systems employing a deterministic activity

PAGE 25

14 network approach which combines simulation and optimization techniques. Their model can be characterized as a field-scale model. They assumed that the farm is well equipped with all necessary machinery for the crops considered and there are no constraints on scheduling of different field operations. Chen and McClendon (1985) and Smith (1985) have developed simulation models for handling double crop systems (two crops in one year). Chen and McClendon 's simulation model is designed for soybean and wheat as double cropping. On the other hand, Smith's model (CROP-PLAN) handles a variety of single crops and is developed to work on an electronic spread sheet package such as Lotus 1-2-3. Limitations To add to the general constraints of the conventional approach to simulation discussed in Chapter I, the farm-scale simulation models reviewed and discussed above have been found having the following limitations. 1. The farm-and-region specific knowledge is generally "hard wired" in their computer code. This makes them very location specific and inappropriate for other locations with a different type of farm setting. 2. They permit assigning of only one tractor to an implement. Farmers with more than one tractor at their disposal in real world situation can operate the same implement with different tractors based upon their

PAGE 26

15 availability. They also have a set of priorities for assigning different tractors to different implements. 3. The available work hours for different operations are estimated using uniform rules for all operations based upon the soil moisture characteristics and/or historic workable days data (Bender, 1984; Rumsey et al., 1986). In most situations, farmers use heuristics for deciding daily working hours specific to each crop and each operation. For example, different amounts of rain make farmers stop different operations. Certain operations such as land preparation could be stopped even with slight rains. On the other hand, critical operations such as planting or baling dry hay could be continued till the heavy rains make it impossible for the farmer to work in the field. 4. They do not allow for irrigation days which make the field non-available for other operations. This results in an over-estimation of available time for plant protection operations. 5. They are generally designed with limited interfaces that require laborious entry of data files and study of many pages of detailed output. This restricts their ability to interact with the user as decision-aid tools. Even though it has been long recognized by machinery management experts themselves that the computer models with no support to teach or guide the user on how to utilize its results would find limited success (Eisgruber, 1968) .

PAGE 27

16 Knowledge Engineering Concepts and Applications Knowledge engineering includes the task of acguiring knowledge, and designing and building knowledge-based systems. It deals with the representation and use of knowledge in electronic form to solve problems that normally require human intelligence or attention. Users can refer to knowledge-based systems in much the same way as they might refer to an expert, consultant and advisor. These systems intend to alleviate man-computer communication problems. In knowledge-based systems (popularly known as expert systems) "knowledge" rather than "data" is the essential raw material to be processed. The data are "facts and figures from which a conclusion can be inferred." On the other hand, knowledge is "a clear and certain perception of some thing, the act, fact or state of knowing and understanding" (Webster, 1979, page 1007) . In artificial intelligence knowledge-base is a body of facts, rules and heuristics which form the basis of knowledge systems. The information about other information in a knowledge-base or knowledge about knowledge is referred to as meta-knowledge (Williamson, 1985) . Different individuals can derive different knowledge from the same data set depending upon their level of expertise and metaknowledge.

PAGE 28

17 Knowledge Classification Knowledge has been classified differently by different authors. Addis characterizes knowledge in three groups: asserted knowledge, heuristic knowledge and mode of inference (Addis, 1985) . Williamson (1985) classified it as 1) descriptive knowledge, 2) prescriptive knowledge and 3) heuristic knowledge. The knowledge required to represent a dynamic system and to predict its operational behavior, as mentioned in Chapter I, can also be classified into three broad categories: 1) quantitative knowledge, 2) qualitative knowledge and 3) procedural knowledge . Quantitative knowledge can be expressed in terms of numbers and mathematical equations. A typical example of such knowledge for an operational farm system could be the rate equation which governs the work capacity of a machinery set based upon its operational parameters. Qualitative knowledge, generally difficult to express in numeric form, consists of a set of heuristics and rules of thumb governing the system. The preference of the farmer for one field over another in allocating available machinery for an operation is a typical example of this type of knowledge for a farm system. Procedural knowledge, also referred to as prescriptive knowledge by Williamson (1985), deals with prescribing a course of action in the presence of certain conditions. A

PAGE 29

18 set of conditions to be checked prior to starting an operation on a field is a typical example of this knowledge type. Knowledge-Based Decision Systems Knowledge-based decision systems are integrated systems which combine simulation and knowledge systems and necessary databases (Shannon, 1984) . The main idea behind these systems is to impart a component of "intelligent" functions in the simulation process, generally performed by human experts, to the computers. Such programs are reported to have high acceptability by agricultural computer users (Smith et al., 1988) . In a knowledge-based decision system, simulation provides a model of the world which can be used to test ideas before they are tried in the real world. The knowledge system, on the other hand, provides a model of an expert which can be used to discuss ideas before they are tried in real world. Thus, the integrated system can be used for discussing possible results of a problem without trying them in the real world (Gaines and Shaw, 1986) . The integration could also provide a media which would be a two-way interaction between a computer and its user ( Intel liCorp, 1988) . Approaches to development The approaches to developing knowledge-based decision systems can be broadly classified as hybrid approach and

PAGE 30

19 knowledge-based simulation approach (Moser, 1986; Beck and Jones, 1988; 0' Keefe, 1986; Umphress and Pooch, 1987; Shaw and Gaines, 1987) . Hybrid approach is the most popular form of integrating simulation and knowledge systems. In this approach, the knowledge systems and simulation models, developed separately, are combined to work together. The simulation models available for the system and/or specially developed for the purpose are written using one of the procedural languages such as FORTRAN, BASIC or PASCAL. The knowledge systems are written in one of the artificial intelligence languages or specialized shells. In this combination the simulation model provides the knowledge about the system for the defined set of circumstances and knowledge system interprets it for the user. Most agricultural decision systems, discussed later in the chapter, have been developed utilizing the hybrid approach. One problem of this approach is incompatibility of languages used for the two components, the simulation model and the expert systems. This increases the resource (both software and hardware) and time requirements for their development. In the knowledge-based simulation approach the simulation and knowledge systems are written using one single environment thus providing a seamless system. In this approach, components of many models may be organized into a model-base

PAGE 31

20 (Reddy et al., 1986). The model-base acts as a library which can be consulted for developing a specific model to address a particular problem. The artificial intelligence techniques are used to organize the model-base and also to identify those models needed for a specific goal and design. In addition, models can be integrated with databases and other application programs . The concept of modelling in knowledge-based simulation approach is fundamentally altered (Oren and Zeigler, 1979; Oren, 1986) . The artificial intelligence techniques capture knowledge about models themselves (meta-knowledge) in addition to knowledge of biological and physical processes captured within the models. Languages for development The computer programs written in conventional programming languages speak in an imperative mode. They say, "do this, then do this." The programmer has to define every step the computer should go through in order to attain the objective. The knowledge-based systems needs to represent the system in more descriptive rather than in an imperative mode. The programmer, known as knowledge engineer, in this case describes the system in the form of knowledge-bases. He needs to describe more clearly what to do rather than how to do. This makes most conventional computer languages less suitable

PAGE 32

21 for developing such systems. Specialized languages and shells used to facilitate their implementation are discussed below. Object-oriented programming (OOP) . In these languages and environments (various versions of SmallTalk (Stefik and Bobrow, 1986) ) , the "objects" become the principal focus of attention. The whole world of interest is expressed as a collection of objects grouped into different classes (refered to as object-class in this dissertation) and with a mechanism by which they can communicate with each other and generate new objects (Stefik and Bobrow, 1986; Lai et al., 1987; Pascoe, 1986) . A specific instance of an object-class (refered to as object-item in this dissertation) is generated when unique values are allocated to different attributes of an objectclass. The representation of knowledge in different classes and subclasses in an hierarchical manner facilitates the development, utilization and maintenance of knowledge-based systems. However, PC-based systems are not yet sufficiently powerful to handle operational scale applications using this approach. PROgramming in LOGic (PROLOG) . PROLOG is one of the most widely used language for writing knowledge systems in Japan and Europe. It is considered as a development tool. It contains a basic scheme for representing knowledge (a common characteristics of a programming language) and also

PAGE 33

22 has a built-in inference engine which conducts its searches to achieve its goal. A program in this language is a collection of facts and rules about different object-classes and their items of the world of interest. From this collection, PROLOG derives solutions to the questions by searching for clauses that are true. The symbol and list processing capabilities, and recursion in PROLOG facilitate handling qualitative knowledge in addition to quantitative knowledge. In recent years, there have been a few attempts to develop simulation programs and simulation languages using PROLOG as a base language (Adelsberger, 1984; Futo and Gergely, 1986; Kornecki, 1986; Yokoi, 1986). Efforts have also been made to develop object-oriented programming languages using PROLOG (Futo and Gergely, 1987; Fan and Sackett, 1988) . The simulations in PROLOG have also been referred to as goal-oriented simulation or logic-based simulation. PROLOG provides a unique environment for developing seamless knowledge-based systems (Shintani et al., 1986; Walker et al., 1987) and was also selected for this dissertation work. Both simulation and knowledge systems can be developed under one single environment. In addition, it provides the following advantages for writing simulation: 1) It allows specification of the system in a much more descriptive manner than most procedural languages.

PAGE 34

23 2) It provides a convenient design facility. It permits natural-language-like sentences which facilitate better understanding of program logic. 3) The inferencing capability of PROLOG can be utilized to diagnose causes for poor performance of the real system. The system can then help the user in the process of designing an improved plan for operations. List Processing (LISP) . LISP is the second oldest computer language. It has two data structures: atoms and lists. An atom is an element which cannot be divided further. A list may be made up of atoms and of other lists. Lists are separated from each other by parentheses. People who find it difficult to keep track of the proper combination of parentheses call LISP "Lot of Irritating Silly Parentheses" (Williamson, 1985, Page 63) . LISP works by manipulating lists. It can also handle recursive procedures. The data and procedure in LISP take exactly the same form. Both are written as lists, what is a procedure in one program can be data in another. The LISP programs are also very demanding of computer memory. The microcomputers generally run out of memory before LISP can perform any significant task. Therefore, specialized LISP machines have been developed to handle LISP programs.

PAGE 35

24 Specialized development shells . The specialized development shells accommodate the "synthesis" concept of problem solving. It is an intermediatory concept between "thesis" and "antithesis" (Walker et al., 1987). The concept of thesis states that the general methods of expert problem solving can be found, made computational, and applied to many different problems (Newell and Simon, 1963) . On the other hand, the theory of antithesis put forward by Fiegenbaum (Feigenbaum and McCorduck, 1983) states that rather than generality, we should set out empirically to capture human knowledge and procedures for each specific task. Intelligence and reasoning power alone are not enough, knowledge is needed for each specific problem. It means that we should be willing to write a new program for each task. The theory of synthesis essentially takes the middle ground. The idea is that many tasks have requirements in common, and these requirements can be met by knowledge systems development shells. These shells are knowledge-less problem solver tools to which the knowledge about particular tasks can be added. They consist of a knowledge representation scheme, an inference or search mechanism, a means of describing the problem and a way to determine the status of the problem while it is being solved (Citrenbaum et al., 1987). There are a large number of commercial shells available in the market. They range from interpreters of relatively

PAGE 36

25 simple languages to very elaborate development environments (Pepper, 1986) . The selection of an appropriate tool for developing knowledge-based systems depends upon factors such as cost, availability of hardware, and type and specification of problem domains (Elmaghraby and Jagannathan, 1986) . Engel et al. (1988) provide comparative evaluation of different knowledge systems shells available on the market and a procedure for selecting the most appropriate for the specific appl ications . Steps in development The steps in development of knowledge-based systems can be broadly divided into 1) problem identification and conceptualization, 2) knowledge acquisition, representation and manipulation, and 3) verification and qualification of the system (Waterman, 1986; Hayes-Roth et al., 1983; Halterman et al., 1986). All of these stages are interrelated and interdependent. They need continuous recycling until the system consistently produces the correct solutions. The problem identification for knowledge-based system is a critical step in its development process. Some of the criteria for identifying candidate problems are 1) recognized expert (s) exist and can solve the problem significantly faster and/or more accurately than non-experts, 2) experts are available to work on the project, 3) the problem solving task

PAGE 37

26 routinely needs to be taught to others, 4) the problem is we 11 -bounded, 5) solutions can be validated and 6) the impact of the system can be measured (IntelliCorp, 1988) . The successful implementation of a knowledge-based system for an appropriate problem depends upon acquiring the knowledge from domain expert (s) and representing it for manipulation within the framework of the selected tool. A great amount of work is being done in developing efficient means for acquiring knowledge from domain experts (Jones et al., 1986; Prerau, 1987). However, a new trend is for the experts to write their own knowledge systems utilizing their own knowledge (Ogilvie, 1988, Personal Communication). Finally, the development of a knowledge-based system is not complete until it has been verified for its functionality. In general, the model testing can be divided into verification and validation. However, in case of the knowledge systems, the validation has been termed as "qualification" (Wildberger, 1988) . The qualification process of knowledge-based system involves letting a team of peers evaluate and critique the system in terms of its knowledge, logic, functioning, userinterface, etc. It is analogous to a procedure used to certify a human expert for his expertise. A knowledge system designed to identify crop insect (s) and to make recommendation on their control should be subjected to the same kind of the qualification tests as an entomologist.

PAGE 38

27 The verification and qualification of knowledge systems may never end as they are never complete. Like human experts, they should grow and adapt to additional knowledge as it is gained. However, researchers are working on algorithms to verify the consistency and completeness of knowledge-bases and the recommendations developed by such systems (Nguyen et al., 1987) . Appl icat ions Applications of knowledge-based systems can be found virtually in every walk of human life. They range from making financial investment and marketing decisions (Thieme et al., 1985; Bulkeley, 1986; Phillips and Harsh, 1987), to better management of resources (Coulson, 1987; Davis and Nanninga, 1985) , to factory design and industrial research (Fisher, 1986; Moralee, 1986). Some of the earlier, more popular and commonly cited knowledge systems (Morrison, 1985) are DENDRAL (for identification of chemical structure of compounds) , MACSYMA (for complex symbolic mathematics) , MYCIN (for diagnosing bacterial infection and suggesting treatments) , XCON (for designing microcomputer configuration) and PROSPECTOR (for identifying potential locations of mineral deposits). Most of these applications are pure rule-based with no integration of simulation or any other type of models.

PAGE 39

28 The agricultural applications of knowledge-based systems can be broadly divided into two categories namely 1) pure rule-based systems and 2) knowledge-based decision systems. Most of the pure rule-based applications are built using development shells on microcomputers. They do not operate any external programs or access any data produced by them. Their applications range for selecting a particular type of machinery (Gibson et al., 1986; Negahban et al., 1988), for identifying pests and diseases and recommending appropriate control remedies (Jones et al., 1986b, Donahue et al., 1988; Gibson et al., 1986), for irrigation design, planning and control of soil erosion (Thomson and Peart, 1986; Bennett et al., 1988; Engel et al., 1988a), for controlling and managing green houses (Jones and Haldman, 1986) , to forest road planning (Thieme et al., 1986), for managing animal waste, weed growth in soybean and other crop production related problems (Smith et al., 1985; Ruckman, 1986; Kalkar and Goodrich, 1986; Nagarajan et al., 1987; Rettinger et al., 1987) , and for determining bottlenecks in on-farm grain processing systems (Loewer et al., 1988) . Role of such systems in technology transfer, education and research has also been emphasized by many researchers (Barrett et al., 1985; Jones and Hoelscher, 1987; Lai et al., 1987; Slocombe, 1986). The knowledge-based decision systems for agricultural applications have been developed using both hybrid and knowledge-base simulation approach (Beck and Jones, 1988) .

PAGE 40

29 The typical examples of the hybrid approach are the systems reported by Jones et al. (1987), Batchelor et al. (1987), Lemmon (1986), Kline et al. (1987), Khuri et al. (1988) and Yost et al. (1986). Jones et al., 1987 describe a system that recommends insecticide applications for the soybean crop. A built-in economic model determines treatment thresholds based upon market value of the crop, cost of insecticide, stage of crop growth and expected yield. It then utilizes the built-in heuristics to select the appropriate insecticide. The soybean pest management system (SMARTSOY) of Batchelor et al. (1987) uses scouting data and expert knowledge to project insect population for a week in the crop. The estimates of damage potential by the insects in the field are computed and are then used as input to the SOYGRO a soybean crop growth model (Jones et al., 1988) to estimate yield losses if control actions are not taken. The system then recommends the type of insecticide to apply depending upon the yield loss and grower sensitivity to risk. The knowledge system is written in Levels and the simulation model is in FORTRAN. The COMAX/GOSSYM (McKinion and Lemmon, 1985a; McKinion and Lemmon, 1985b; Lemmon, 1986) works on a concept similar to SMARTSOY. It recommends optimum scheduling of fertilization, irrigation and harvesting for cotton crop.

PAGE 41

30 GOSSYM is a cotton growth simulation model written in FORTRAN and COMAX is the knowledge system part written in common LISP. A system for analyzing the results of a linear programming model aimed at selecting optimum combinations of machinery systems for a crop production have reported by Kline et al. (1986, 1987) . Citrus Harvest Expert Simulation System (CHESS) , developed by Khuri et al. (1988), interprets the results of Citrus Harvesting Simulation Model (MACH II) written in the SLAM II simulation language (Pritsker, 1984) and recommends to the user how the harvesting operation can be improved. The system developed by Yost et al. (1986) recommends the appropriate dosage of lime for crop production for tropical soils. It uses a set of equations to compute the lime requirement and the relative yield loss without lime application based upon crop, location and its soil type. 1e system checks the preconditions and qualifications which must be evaluated in order to use these equations properly. Agricultural applications using the knowledge-based simulation approach are rather few and most of them are in their initial stages of development. COTFLEX is a farm level decision support system for individual crops (Stone et al., 1986; Helms et al., 1987). The frame based representation of farm knowledge allows to store the attributes of the object-classes in their slots. The values for these slots can come from one of four possible

PAGE 42

31 sources namely 1) a simulation, 2) an expert system, 3) a data base or 4) the user himself. CALEX is a farm level decision system which consists of an executive program which provides and controls the access to data files, the knowledge systems and the simulations. Facilities are provided by which the expert system can call a simulation and vice-versa. It stresses the record keeping aspect of farm management decisions (Plant and Wilson, 1986; Plant et al. , 1987) . POMME is a decision support system for apple orchards (Roach and Virkar, 1986) which can advice on various production practices including pest control recommendations. An ADaptive Assembler for Models (ADAM) organizes equations for calculating parameter values when several alternative equations may be available (Whittaker et al., 1987) . It has been applied to the domain of soil erosion modelling. It can help identify the erosion equation appropriate for a particular situation. The WHeAt Modelling expert system (WHAM) also uses heuristic rules to assemble model components from a modelbase into a simulation to answer user's question (Rimmington et al., 1987). In operation, the user specifies a set of output variables to be predicted by the model. The modelbase is then activated to locate and assemble models which can satisfy this goal.

PAGE 43

32 Some of the most recent developments of integrating knowledge engineering concepts with data processing techniques as applied to agriculture were presented and are compiled in the proceeding of a conference on "Integration of expert systems with conventional problem solving techniques in agriculture" (AAAI and ASAE, 1988) .

PAGE 44

CHAPTER III SYSTEM DESIGN AND IMPLEMENTATION An integrated decision support system should interact with the user to collect information about the system, analyze it utilizing the knowledge (both procedural and heuristics) captured within itself, and provide the user with expert help to improve the productivity of the system in the context of the input knowledge as depicted in Figure 3.1. A decision support system consisting of four components: Operations Simulator, Expert Analysis System, Yield Estimation System and Information Management System has been designed and implemented using knowledge engineering concepts of Artificial Intelligence. The integrated system has been refered to as FARMS YS and discussed in this chapter. The Operations Simulator simulates the field operations for the complete cropping season with a one-day time step. The Expert Analysis component examines the simulation reports and makes recommendations for planning decisions of an operational farm. The Yield Estimation component estimates the crop yields and profits from different fields, crops and the whole farm, and the Information Management System is an intelligent user-interface to gather information from the user 33

PAGE 45

34 INPUT KNOWLEDGE PROCEDURAL KNOWLEDGE SIMULATION REPORTS EXPERT ANALYSIS SYSTEM Figure 3.1 Functioning of an integrated decision support system

PAGE 46

35 and to let him make changes in the existing farm knowledge. The hierarchical representation of these components of FARMSYS is presented in Figure 3.2. The overall of goal of such a system is to provide a planning and/or management tool for researchers, educators, perhaps farmers, to "test" combinations of resources such as equipment, crop mixes, labor, procedures (no-till, minimum till, etc.) and weather for timeliness, yields and efficiency of utilization of resources. It can be utilized for evaluating the performance of different farms for a particular weather year or to evaluate the performance of the same farm over different weather years with different combinations of labor, machinery and crop combinations. The languages and development shells explored for the dissertation work are SmallTalk V (Digitalk, 1986) , VP Planner and VP Expert, a combination of spread sheet and expert system shell (Paperback Software International, 1985) and Turbo PROLOG (Borland, 1986) . And the Turbo PROLOG was selected for the final implementation of the system, because it provided an environment for simulating field operations in an object-oriented manner, an efficient depth-first search mechanism for the expert systems inferencing and an appropriate frame work for representing farm, regional and expert knowledge in the format of semantic nets, a popular AI knowledge representation technique.

PAGE 47

36

PAGE 48

37 Simulation in an object-oriented manner implies representation and manipulation of farm knowledge as a collection of objects along with a mechanism by which they interact with each other and with the environment over time. This approach enabled modelling the decision behavior of the farm manager in a more realistic fashion than is generally captured in the conventional approach to simulation in procedural languages. In addition, PROLOG also permits compiling the final program in the format of a executable file which can be distributed to users with no obligations of any run-time versions. Object-Oriented Simulation The model simulates field operations for an operational farm system with given machinery, labor, crop combinations, work schedule and other farm specific parameters. The process of simulating agricultural field operations involves both discrete events and continuous processes comprising of many activities and numerous state variables. The decision about the earliest start and latest finish times for different operations in a cropping seguence is a typical example of discrete events. The scheduling of these operations within their agronomic work windows and allocating the machinery as well as labor to different fields to carry out these operations are the examples of event happenings.

PAGE 49

38 On the other hand, once an operation starts its execution is then controlled by a continuous rate process depending upon the machinery capacity, climatic and other management factors. The general sequencing of the operation types for crop production is land preparation, fertilizer application and planting, plant protection and harvesting. Each of these could contain one or more operations and are the processes of the system which are controlled by their state variables which change dynamically with time. All these factors make the task of developing a model which would emulate the behavior of an operational farm system very complex and challenging. The inputs for the model for a farm can come either from its present mode of activities or from a representative farm of the region. The initial cropping systems for a farm can be selected from the ones most appropriate for the region which depend upon climate, government policies and other market information about the region as depicted in Figure 3.3. Farmers goals and his preferences, irrigation facilities at his disposal, and his financial situation play key role in making selection of cropping systems for his farm situation. The selected cropping systems along with machinery and labor, agronomical inputs and management decisions when applied to farm fields result in crop production for the market and/or home consumption.

PAGE 50

39 CLIMATE GOVT. POLICIES MARKET INFO INDV. PREF. AND GOALS REGIONAL CROPPING SYSTEMS IRRIGATION FACILITY FINANCE/ BANKS AGRONOMICAL INPUTS SELECTED CROPPING SYSTEMS MACHINERY AND LABOR MANAGEMENT DECISIONS CROP PRODUCTION Figure 3 . 3 Objects and environment of an operational farm system with crop production activity.

PAGE 51

40 The inferencing capability of logic programming (PROLOG) employed for writing the simulation facilitated to incorporate several expert systems within the simulation to make heuristic decisions and other types of searches at various stages of the simulation. Farm as a System The farm is a complex system and is considered as an intermediate level in hierarchical representation of an agricultural system (Hart, 1984) . It contains many subsystems and sub-subsystems. Each of these systems contain many object-classes and object-items along with their attributes and values. Table 3.1 presents the object-classes with their attributes needed for simulating field operations for an operational farm system, and the specific items of each type of these object-classes with their attributes are depicted in Figure 3 . 4 for the Davis farm used as a test farm for the operational verification of the model discussed in chapter IV. The interrelationship between different farm objectclasses in the form of the semantic nets is shown in Figure 3.5 and discussed below. The farm has a name, location, total area, cultivated area, a principal activity and an extension code name for storing its (farm) information. It possesses fields, crops, implements, tractors, laborers and a work schedule.

PAGE 52

41 farm ( "DavisFarm" , "SantaRosa" , 400 , 400 , "CropProduction" , "dvs" ) labor ( "Laborer_l" , "Jerry" , "m" , [ "General" ] , "Avail") tractor ( "Tractor_l" , "JD4450" , 148 , [ "Jerry" ] , "Avail") implement ( "Implement_2" , "LandPrep" , "DiskHarrow" , [ "Tractor_l" , "Tractor_2" ] , 4 . 74 , 7 , "Avail" ) crops ( "Crop_3" , "Wheat" , [ "Fertilize" , "Harrowing" , "Plowing" , "Planting" , "FertiSpreading" , "Harvesting"] ) fieldi("Field_l", "fieldl", 20, "SandyLoam", ["Cotton", "Wheat"] , ["DPL41", "FL3 02"] , [150, 165], ["Fertilized", "Fertilized"], "Notlrrigated" , "NotNeeded", [750,125], [1200,110], "Avail") operations ("PlantFertiOps", "Planting", "Soybeans", 136, 182, [[0,3,1], [3,8,0.5]] , [ "Planter_77" ] , 0.76) Figure 3.4 Examples of items of different object-classes of Davis farm in the format of dynamic databases of PROLOG.

PAGE 53

42 CO CO < cr HI Q. o o o CO CO UJ ' CL o' °1 _l

PAGE 54

43 Table 3.1 Farm Objects and their Attributes Objects Farm Labor Tractor Implement Irrigation Equipment Crop Field Attributes Name, Location, Total Area, Cultivated Area, Principal Activity, Farm Code Number, Name, Sex, Functions, Availability Model, Hp, Operators List, Availability Number, Type, Name, Tractors/ Operator List, Width, Speed, Availability Number, Specification, Capacity, Operators List, Availability Number, Name, Operations List Number, Identification, Area, Soil Type, Crop List, Variety List, Maturity Days List, Fertilizer Type List, Irrigation Type, Production Cost List, Sale Price List, Availability Operation Type, Operation Name, Crop, Earliest Start Time, Latest Finish Time, Work Hours Conditions List, Implement List, Efficiency Month, Schedules Daily Working Hours Operations Scheduled Work Hours

PAGE 55

44 A laborer has his/her name, sex, functions and availability status. The number of laborers available on a farm could depend upon its size, mechanization level and cropping intensity. A tractor has a number, make and model, horse power, a list of operators and its availability status. The horse power of the tractor controls the type of implement it can operate. The operators list contains the names of the farm laborers who can operate the tractor. Irrigation equipment, similar to a tractor, has a number, specification, capacity, list of operators and its availability status. If the equipment does not need any operator during its operation, then its operator list could contain "NotNeeded." An implement is characterized by its type, name, working width, speed of operation and a list of tractors or operators needed to operate it. For a self-propelled and manually operated implements, the list contains the names of the laborers who can operate the implement. In case of the implement which needs a separate power unit for its operation, this list consists of tractors or animals needed to power the implement. For completing the machinery system for such an implement, the laborer needed to operate the implement is selected from the list of laborers attached to the selected power unit for use with the implement.

PAGE 56

45 A crop has a number, its name and a list of operations needed to grow it. In addition, the variety, number of days for maturity after planting, the fertilization level, the production cost and the sale price associated with the crop are also assigned to the field on which it is grown. A field has a number, its name, the area, the soil type, irrigation facility, etc. It can be utilized to grow two crops in a year. A farm could have any number of fields as long as the sum total of the fields ' area does not exceed the cultivated area of the farm. An operation has a type, name, earliest start time, latest finish time, work hour conditions, efficiency and an implement list. The earliest start time is the time before which the operation cannot start, and the latest finish time is the time after which the operation should no longer be continued. The work hour conditions associated with an operation are a set of conditions which define how many hours the operation should be carried out depending upon the rainfall and the scheduled work hours for the day. The implement list contains implement names which could be utilized for the operation. The scheduled work hours are daily working hours for each month of the year. It is utilized to estimate the actual work hours for different operations based upon their work hours conditions and rainfall of the day.

PAGE 57

46 In addition to the farm objects, the simulator also needs local weather and evapo-transpiration data and crop irrigation requirements for scheduling irrigations. Knowledge Representation The information about different farm objects for the simulation is stored in the form of relational tables (referred as dynamic databases for Turbo PROLOG) . It is a special feature of the logic programming environment which facilitates representing facts about the objects and their relationships within the system. It can include qualitative knowledge, in addition to quantitative and procedural knowledge, which would have been difficult to do in conventional programming environments. The preference of the farmer for selecting operators out of his labor crew for a tractor and assigning an order of priority for each of them is a typical example of qualitative knowledge. It has been captured in PROLOG by representing the selected operators in a list and attaching it to a tractor. The search for an operator to work with the tractor is carried from left to right. So, the laborers in this list should be listed in order of preference to operate the tractor. Similar logic applies to the list of the tractors for an implement and to the list of the implements for an operation. In addition, this representation also provides the facility of listing

PAGE 58

47 backup implements for an operation which are generally ignored in conventional programming models of simulation. Model Description The simulation model is structured in two distinct components: a) farm and region specific knowledge, and b) procedural simulation knowledge. The farm and the regional knowledge needed as an input to the simulation is maintained separate from its procedural knowledge. This has made the model a versatile and flexible. It can be utilized for different kinds of farm settings with little or no modifications . Farm specific knowledge consists of a number of ASCII files containing information about the different objects of the farm system in the form of dynamic databases of PROLOG (Figure 3.4 and Appendix I). This component needs to be developed by the user for his specific farm setting utilizing Intelligent Information System discussed later in this chapter . Procedural simulation knowledge is a PROLOG program consisting of several predicates and clauses (discussed later in this chapter) . It carries out the actual simulation. The compiled version of the program cannot be accessed by the user for any modification. The execution of the simulation goes through the following steps in sequence as depicted in Figure 3.6.

PAGE 59

48 GET FARM, WEATHER YEAR(S). SCHEDULED WORK HOURS FIND CROPPING SEASON SELECT FIRST DAY AS CURRENT DAY FOR THE CURRENT DAY MAKE ALL FIELDS, LABOR AND MACHINERY AVAILABLE FOR WORK AND WORK ON FIELD(S) READY FOR OPERATION UPDATE CURRENT DAY BY ONE No CURRENT DAY LAST CROPPING DAY Yes PREPARE REPORTS Figure 3 . 6 Flow chart of execution of the operations simulation

PAGE 60

49 Step 1 . Get farm name and consult all related files. Step 2 . Let the user select weather year and allow him to adjust work schedules, if he so desires. Step 3 . Simulate the operations for the cropping season. This step finds out the first and last day of the cropping season and carries out the following during this time interval . I . Make the first day of the cropping season as the current day and carry out the simulation for the current day using following sub-steps. 1. Make all fields, labor and machinery available for work. 2 . Pick up the first field from the field file and carry out the checks and the actions listed in Figure 3.7 for scheduling irrigation and other field operations. 3. Repeat the above procedure for all fields of the farm. II. Update the current day by one day. III. Check if new day is greater than the last day of the cropping season, if not repeat the above process, else terminate the simulation. Step 4 . Preparation of simulation reports. The simulator prepares five reports. Specific contents of these reports are listed in Table 3.2. The user can access any of them by use of any editor to analyze the simulation results. However, the summary report is automatically displayed on the screen on completion of the simulation.

PAGE 61

50 1) Calculate soil moisture of the day based upon yesterday's ET, rain and irrigation, if any. 2) Check if the field has a irrigation facility and if so find out the irrigation equipment used on the field. 3) Check the availabilities of irrigation equipment and any operators needed to operate the equipment. 4) Check number and amount of pending irrigations 5) Irrigate the field, if soil moisture is below threshold, number or amount of pending irrigations is not zero and irrigation equipment and operator are available. 6) Make the field, the equipment and the operator associated with the irrigation non-available for the day, else do not change their status. Update the soil moisture status of the field irrespective of decision about the irrigation. 7) If the field is not being irrigated, get the list of operations associated with the crop being grown on the field. 8) If the operations list is not empty, pick up first operation from the list. Figure 3.7 Tasks performed by the Operations Simulator for scheduling irrigation and other field operations for a field on daily basis.

PAGE 62

51 9) Check if the operation is the type of operation being tried now. 10) Get details for the operation such as agronomical work window, implement list, etc. 11) Check suitability of the "current day" for the operation with respect to its agronomical work window. The "current day" should be within the work window of the operation. 12) Check the availability of the required machinery set for the operation; the implement and the operator in case of self-propelled implements, and the implement, the tractor (power unit) and the operator in the case of other types of implements. 13) If all the above conditions are satisfied carry out the operation based upon the implement characteristics; working width, speed of operation and actual work hours and operation efficiency. 14) Record the work and no work as applicable and remove the operation from the list, if it has been completed or its latest finish time has passed. 15) Make the machinery set (Implement, Tractor and Operator) and the field not available for the day. Figure 3.7 — continued

PAGE 63

52 Table 3.2. Simulation Reports and their Contents Report Description Contents Work Report for Irrigation Work Report for Field Operations Julian day, field name, irrigation applied (mm of water) , irrigation equipment and operator used, day's soil moisture, pending number of irrigations and their amount. Julian day, month, field, crop, operation, total area, accumulated done area, day's work, implement, tractor, operator, and number of hours worked. No-Work Report for Irrigation No-Work Report for Field Operations Summary Report for Field Operations Julian day, month, field, crop, irrigation equipment and its availability report, operator and its availability report. Julian day, month, field, crop and operation, total area, done area, reason of no-work, implement list and its availability report, operator list and its availability report, tractor list and its availability report . Field, crop, operation, scheduled start and finish times, actual start and finish times, number of days and hours worked, total done area, number of non-working days.

PAGE 64

53 In the process of the simulation the fields are served on a first-come first-serve basis. The user should enter them in order of the priority that he wants them to be checked for different operations. The priority for different operations is built-in the program code. Irrigation, if the field has irrigation facility, is given the highest priority followed by harvesting, plant protection, planting and land preparation operations. However, the structure of the simulator permits one changing the priority to suit specific cases. Machinery and labor present on the farm are assumed to be available for work for the complete duration of scheduled work hours. They are also assumed to have 100% reliability within the operational efficiency defined for the operation they are assigned to perform. Simulation in PROLOG PROLOG is an AI language which has been utilized for developing knowledge systems. The use of this language for simulation is rather recent and limited. Therefore, this section explains how PROLOG has been utilized for carrying out the present simulation. A program in Turbo PROLOG consists of five sections namely domains, databases, predicates, clauses and a goal. The sections of predicates and clauses are the principal ones. A predicate is declared by stating its name and the domains

PAGE 65

54 of its arguments. A clause is either a fact or a rule corresponding to one of the declared predicates. Borland (1986) describes the contents of each section in detail. PROLOG has a built-in inference engine which searches through the knowledge-base in a backward chaining manner. In this mode, a goal to be achieved is pursued by searching through the true clauses. It includes a pattern matcher, which retrieves stored (known) information by matching answers to the questions. The information supplied to PROLOG (the facts about the objects of the system and rules governing their actions and behavior) become the finite set of knowledge to work on. In addition to logically finding answers to questions, PROLOG can deal with alternatives and find all possible solutions rather than only one. Instead of proceeding from the beginning of the program to the end, PROLOG can actually back up and look for more than one way of solving each part of the problem. This process of backing up is known as "back tracking" and can be achieved by various ways as discussed by Flowers (1988) . The process of "back tracking" has been utilized for simulation in PROLOG to develop an effect similar to looping in conventional procedural languages. A simplified version of the actual program code of the simulator is presented in Figure 3.8. The given code consists of three principal predicates, "doSimulation",

PAGE 66

55 doSimulation: getFantiKnowledge (labor, field, equipment, crop, irrigate, operation, tractor, implement) , getOtherKnowledge(expertfile, weatherfile, workhrsf ile) , findSimulationDuration(SDay,FDay) , simulateSeason(SDay,FDay) , writeResultFiles (resultl , result2 , results , result4 ) simulateSeason(SDay,FDay) :asserta(currentday (Sday) ) , repeat, currentday(SimDay) , makeAvailAll , simulateADay (Simday, "Irrigation") , simulateADay (Simday, "HarvestingOps") , simulateADay (Simday, "PlantProtectionOps") , simulateADay (Simday, "PlantFertiOps") , simulateADay (Simday, "LandPrepOps") , Sdayl=Simday+l , changeDay(Sdayl) , Sdayl>Fday. simulateADay (SDay,OpsType) :fieldc(FieldN,Crop) , chkCondAndWork ( FieldN , Crop , Sday , OpsType) , fail. simulateADay (_,_) :-! . ChkCondAndWork (FieldN, Crop, _,_) :fieldo ( FieldN, _,_,_, Crop, OpsList,_, OpsList=[ ] , ! . Figure 3.8 Simplified code of operations simulation in PROLOG

PAGE 67

56 chXCondAndWork{FieldN,Crop,SDay,OpsType) :f ieldo ( FieldN , Tarea , CUarea , Darea , Crop , OpsList, _,_,_, _,_,_) , OpsList=[Opsl |_] , type(OpsType,OpsTypeList) , not (member (Opsl,OpsTypeList) ) , operations (_, Opsl , Crop , _, FtOpera ,_,_,_) , chkTimeFinish(Sday,FtOpera,AnsT) , ad j ustParameters (OpsList , Tarea , CUarea , Darea , AnsT , "No" , OpsListl , Tareal , CUareal , Dareal) , recordWork (FieldN , Crop , Tareal , CUareal , Dareal , OpsListl, "Avail") , ! . chlcCondAndWork (FieldN, Crop, SDay,OpsType) :f ieldo (FieldN , Tarea , CUarea , Darea , Crop , OpsList, _,_,_, _,_,_) , OpsList=[Opsl j_] , fieldi (FieldN, _,_,_, [Cropl,Crop2] , Crop=Crop2 , not(Cropl="NoCrop") , f ieldo ( FieldN, _,CultArea,_,Cropl, CurOpsList, _,_,_, _,_,_) , decideWork3 (CurOpsList, CultArea, Reason) , recordNoWork ( Sday , FieldN , CUarea , Crop , Opsl , OpsType, Area, Reason, [ ] , "NotChecked" , [ ] , " NotChecked" , [ ] , "NotChecked") , operations (_, Opsl , Crop ,_, FtOpera ,_,_,_) / chkTimeFinish (Sday, FtOpera, AnsT) , ad j ustParameters (OpsList , Tarea , CUarea , Darea , AnsT, "No", OpsListl, Tareal, CUareal, Dareal) , recordWork ( FieldN , Crop , Tareal , CUareal , Dareal , OpsListl, "NotAvail") , ! . chkCondAndWork (FieldN, Crop, Sday, OpsType) :f ieldo (FieldN , Tarea , CUarea , Darea , Crop , OpsList, _,_,_,_,_, "NotAvail") , OpsList= [Opsl ] _] , recordNoWork (Sday , FieldN , CUarea , Crop , Opsl , OpsType, Area, "FieldNotAvail" , [ ] , "NotChecked" , [ ] , "NotChecked" , [] , "NotChecked") , operat ions (_, Opsl, Crop, _, FtOpera, _,_,_) , ChkTimeFinish ( Sday , FtOpera , AnsT) , ad j ustParameters ( OpsList , Tarea , CUarea , Darea , AnsT, "No", OpsListl, Tareal, CUareal, Dareal) , recordWork (FieldN , Crop , Tareal , CUareal , Dareal , OpsListl, "NotAvail") , ! . Figure 3.8 — continued

PAGE 68

57 chlcCondAndWork(FieldN,Crop,SDay,OpsType) :f ieldo ( FieldN , Tarea , CUarea , Darea , Crop , OpsList, _,_,_, _,_,_) , OpsList=[Opsl j_] , operations (_, Opsl , Crop , StOpera , FtOpera , OpsCondList,IinpList,Eff ) , chktime ( SDay , FieldN , Crop , Opsl , StOpera , FtOpera, AnsT) , decideWorkl (SDay , FieldN , CUarea , Crop , Opsl , OpsType,DArea,Ans) , MachinesLAvail (ImpList, Implement, Tractor, Operator, ImpWidth, Speed, AvailI,TraList, AvailT , OprList , AvailO) decideWork2 (SDay , FieldN , CUarea , Crop , Opsl , OpsType , DArea , ImpList , Avail I , TraList , AvailT, OprList, AvailO) , weather(Sday, Month, _,_,_, Rain) , workHrs (Month, WrkHrs) , calculateHrsIndOps(OpsCondList,Rain, WorkHrs, WrkHrs) , dayWork=Speed*ImpWidth*Ef f *WorkHrs/10 . , TDarea=Darea+DayWork , ChangeOpStday(Sday, FieldN, Crop, Opsl) , chkTimeFinish(Sday, FtOpera, AnsT) , chkAreaF in ish (CUarea , TDarea , AnsA) , ad j ustParameters (OpsList , Tarea , CUarea , TDarea , AnsT, AnsA, OpsListl, Tareal, CUareal, Dareal) , recordWork (FieldN , Crop , Tareal , CUareal , Dareal , OpsListl, "NotAvail") , makeMachinesOccp (Tractor , Implement) , makeEntityOccp( labor, Operator) , minR (TDarea, CUarea, DareaR) , maxR(CUarea,DareaR,CUareaR) , wr iteworkreport (SDay , Month , FieldN , Crop , Opsl , CUareaR, DareaR, DayWork, Implement, Operator, Tractor, WorkHrs) , ! . chkCondAndWork (_,_,_,_) :-! . Figure 3.8 — continued

PAGE 69

58 "simulateSeason" and "simulateADay" which work in an hierarchical order. They can be thought of as subroutines in procedural languages. The predicate "doSimulation" creates the necessary conditions for the simulation by bringing the farm as well as other knowledge to the memory using predicates "getFarmKnowledge" and "getOtherKnowledge. " It then calls "simulateSeason" and writes reports on successful completion of the seasons 's simulation. The "simulateSeason" predicate has two arguments: start day (SDay) and finish day (FDay) . The Turbo PROLOG predicate "asserta" puts "SDay" into the dynamic database "currentday. " Then it collects the same day value by use of the database predicate "currentday (SimDay) . " Then it calls "simulateADay" five times with the current day and different operation types. The order of calling this predicate with different operation types determine their priority over one another. Under the current format irrigation gets the highest priority followed by harvesting, plant protection, planting and fertilizer application, and land preparation operations. On the successful completion of the one-day simulation, the current day is updated by one day (Sdayl=Sday+l) , and the content of the "currentday" database is changed by the use of predicate "changeDay." Finally, a check is made to see if the updated day is greater than the last day for the simulation (Sdayl>Fday) . This condition is satisfied when the simulation

PAGE 70

59 for the whole period is completed, otherwise the condition fails and backtracking begins. The backtracking proceeds up through different predicates until it encounters "repeat." The "repeat" predicate is a non-deterministic clause which always reverses the backtracking process. On the reversal of the process, PROLOG finds the content of the "currentday" database changed and picks it up for further actions of calling the "simulateADay" predicate with the new day. The process is repeated with one day increments until (Sdayl>Fday) becomes true and the execution of the predicate "simulateSeason" is successfully completed. The "simulateADay" predicate is designed to carry out one day simulation for the current day (Sday) and the given operation type (OpsType) . The dynamic database "fieldc" consists of entries of all the fields with the crop being grown on them. These entries are made in order of priorities of the fields to be served by the simulator. During execution of this predicate, the first field (FieldN) and the crop (CropN) being grown on it are given to predicate "chkCondAndWork" to carry out its task. The predicate "chkCondAndWork" checks various conditions and carries out different actions as listed in Figure 3.8 for the simulation. It also calculates the amount of work done based upon the available machinery set and prepares different reports .

PAGE 71

60 On successful completion of the task of "chkCondAndWork" for the current field, crop and operation type, the predicate "fail" causes the clause to fail and forces it to backtrack. In this case, the backtracking occurs up to database predicate "fieldc" which acts like a non-deterministic clause. At this stage PROLOG picks the contents (FieldN and CropN) of the next entry in the database and repeats the steps of this clause in hope of succeeding. However because of the "fail" predicate, it fails again. The process is repeated until all the entries of the "fieldc" database have been tried. Having worked on all the entries of the database "fieldc", the clause fails even prior to calling predicate "chkCondAndWork." Then, PROLOG searches for an alternative "simulateADay" clause or rule, and finds " simulateADay (_,_) :-!.", which always succeeds for any value of SDay and OpsType, thus successfully completing the task of simulation for the instantiated values of the operation type and current day for all fields on the farm. The same process is repeated for all the operation types . The simulation checks the possibility of carrying out all types of operations on every field daily throughout the cropping season. The predicate "chkCondAndWork" does this task very efficiently. Its structure and sequencing avoids deep level searches for the operations on the fields not yet ready to receive them. It is so structured that the actual time for a day's simulation decreases as the work on different

PAGE 72

61 fields is completed and the operations lists associated with them become empty. The "chkCondAndWork" is a multi-clause predicate and it makes use of many other PROLOG user-defined predicates detailed in Table 3.3. The tasks performed by different clauses in order of their listing (Figure 3.8) are as follows. The first clause checks if the current operation list is empty (OpsList=[ ] ) . If this condition fails, which means that there are still some pending operations for the field, PROLOG goes on to the next clause; else, it assumes that the work for a particular call of the predicate is done and returns that message to its user clause ("simulateADay") . The second clause determines if the operation being tried is of the type intended to be examined. If this conditions succeeds, the clause fails and control is passed on to the next clause. Else, appropriate adjustments in the field database are made using "adjustParameters" and "recordWork" predicates without carrying on any further action. The third clause takes care of the fields with sequential cropping systems. It checks if all the operations associated with the first crop grown on the field have been completed. If this condition succeeds, the clause fails and passes the control to the next clause. Else, it prepares a no-work report with the reason determined by predicate "decideWork3" and adjusts the field's records accordingly.

PAGE 73

62 Table 3.3 User-defined PROLOG predicates and their description, used by different clauses of "chkCondAndWork" of the Operations Simulator for scheduling field operations on daily basis. Predicate fieldc fieldo Description a database predicate to control sequencing of different fields in the simulation process. a database predicate containing additional information about fields not included in the "fieldc". field a database predicate to keep track of actual status of fields during various stages of simulation. member operation checks if an object (Opsl) is a member of an object list (OpsTypeListl) . a database predicate to store details about operations associated with different crops. The attributes associated with the operationclass are listed in Table 3.1. chkTimeFinish a predicate with three arguments. It takes "Sday" and "FtOpera" as inputs and checks if current day (SDay) has passed the FtOpera and returns an answer "AnsT" (Yes or No) to that effect. ad justParameter adjusts the values of "OpsList", "Tarea", "CUarea" and "Darea" respectively to "OpsListl", "Tareal", "CUareal" and Dareal" based upon the values of "AnsT" and "AnsA" (Yes and No) which are also supplied as input. It removes the completed operation from the current operations list and set the done area back to zero for the next operation based upon the values of "AnsA" and "AnsT" .

PAGE 74

63 Table 3.3 — Continued Predicate chkAreaFinish recordWork Description recordNoWork decideWork? checks if "Darea" for the current operation has equaled or exceeded the currently used area of the field. records the current status of the field. It removes the old status of the field from the database "field" and asserts a new entry with updated parameters which are received from the predicate "adjustParameters". collects and records information about the work which were attempted but could not be done including its reasons. three predicates: "decideWorkl", "decideWork2" and "decideWork3" are designed to decide further course of action based upon the instantiated values of different variables of their arguments. checks the availability the implement (s) form the implement list "ImpList" associated with the operation. The predicate returns the name of the machinery set (Implement, Tractor and Operator) and its operational parameters (ImpWidth and Speed) . a database predicate stores the daily weather conditions such as Rain, etc. a database predicate stores the daily scheduled work hours on the monthly basis. calculates the actual working hours (WrkHrs) for the operation based its operating conditions (OpsCondList) , rainfall (Rain) and scheduled work hours (WorkHrs) for the day. machineLAvail weather workHrs calculateHrsIndOps

PAGE 75

64 Table 3.3 — Continued Predicate changeOpStday makeMachinesOccp minR maxR writeWorkReport Description changes the earliest start time for harvesting operation based upon the planting date and the number of days required to mature the crop. makes the machinery set "Tractor" and "Implement" including their operator, engaged for an operation occupied; and not available for any other activity for the day. finds out the minimum value "DareaR" of two supplied input values (TDarea and CUareaR) finds out the maximum value "CUareaR" of two supplied input values (CUarea and DareaR) . takes various parameters of the day's work and asserts them to the daily work report.

PAGE 76

65 The fourth clause makes sure, before passing command to fifth clause, that the field being worked upon is available for receiving the services and is not engaged in any other operation, such as irrigation. The fifth clause, the heart of this predicate, carries out the actual task once it receives the command. It makes a few additional checks prior to carrying out the actual task. It checks if the current day is within the operation's work window, searches for the machinery needed for the operation and determines its operational parameters, estimates the actual work hours for the operation for the day and calculates the day's work and accumulated area done by the operation. It adjusts field databases, records work or no-work reports, and makes the machinery and labor utilized in the operation occupied and not available for any other operation for the day. The sixth clause is the terminating clause which always succeeds to continue the process if all the above five clauses fail due to some reason or other. Expert Simulation Analvsis The foremost question in analyzing farming operations is, was a particular operation started and/or completed on time? If an answer to such a question is negative, then the next logical question is, what factors are responsible for the delays, and how they can be overcome?

PAGE 77

66 Farm managers also need to know how different farm implements, power sources and labor performed on his farm during the cropping season. They want to identify underutilized and/or over-burdened machinery and labor in order to better plan their operations for the next season. They may like to arrange supplementary units for the most needed machines or withdraw under utilized machines and labor, if possible. The reports on the performance of any selected combination of items for different farm object-classes can be of great help to farm managers. These reports can be utilized for preparing budgets of different activities either for their own records or for tax purposes. Answers to all above queries are available but hidden in the reports produced by the operations simulation discussed in earlier in this chapter. The output reports produced by the simulation are bulky and complex. Their complexity increases as the farm size (number of fields, crops and machinery resource) increases. Interpretation of these reports in the context of the available machinery and labor resources to respond to above queries is the most critical step in engineering farm knowledge for the decision support system. An expert analysis system is designed and implemented in PROLOG to answer to the above queries based the simulation reports. It is designed to implement a logical reasoning

PAGE 78

67 approach which characterizes delays in operations based upon the built-in or user-supplied heuristics, studies labor and machinery utilization on the farm during the cropping season, and makes recommendations for their efficient planning and management . The expert analysis system consists of three components: 1) Operation Analysis Report, 2) Machinery Usage Report and 3) Accumulated Work Report. All these components are structured to work independently but in harmony with one another. The user can work with them in any sequence he desires. In addition, they work in an interactive and repetitive mode as depicted in Figure 3.9. The user can utilize them to prepare as many reports as he desires. On the completion of each report, the user has the option to quit the program or to get another report for a different set of inputs . The Operations Analysis Report analyzes different operations for their timeliness in start and/or completion. It identifies factors responsible for the delays, if any, and presents them to the user along with the recommendations for their remedies in a cost effective manner. The Machinery Usage Report provides the user with the seasonal and monthly utilization of items of different farm object-classes such as implements, laborers and tractors. It identifies the most and the least utilized items of the

PAGE 79

68

PAGE 80

69 selected class and recommends either to withdraw or to keep the least utilized item based upon its utilization level and its allocation strategy for different jobs supplied by the user for his farm. The Accumulated Work Report provides the user with an aggregate work summary for any combination of the items of different farm object-classes for the desired time interval. Utilizing this report, the user can get answer to guestions such as how many hours "Laborer_l" worked with "Tractor_2" for "Soybeans" fields during January 1 to June 30? The Operations Analysis and Machinery Utilization reports work in a competitive manner with each other. The Operations Analysis report identifies bottlenecks in the farm system and always attempts to recommends for increasing the machinery capacities. On the other hand, the Machinery Utilization report identifies under-utilized machines and laborers, and attempts to recommend their withdrawal from the farm. Therefore, these two reports in conjunction with the Accumulated Work report can be a very effective means of arriving at an appropriate level of machinery and labor for a given farm system. Operations Analysis Report The delays in critical operations such as planting, plant protection and harvesting in crop production can cause serious damage to crop yields. These delays could be due to lower

PAGE 81

70 working hours put in during the operation and/or insufficient working capacity of the machinery utilized. In addition, the delay in one operation may cause holdups in subsequent operations because of their sequential nature. The present report is prepared by utilizing the work summary report of the field operations simulator discussed earlier in this chapter, and it makes use of built-in or user-supplied heuristics to develop various recommendations. Figure 3.10 presents the flow chart of functioning of the report and its development process. For preparing this report, the system goes through a decision process of characterization of the delays, identification of operation (s) to be analyzed and the problems causing these delays, and development of appropriate recommendations. The steps involved in this decision process are discussed below. Characterization of delays An operation is said to be delayed if it is not carried out within a critical time period. This period for an operation could depend upon its type, location, crop and soil characteristics. It is not possible to develop any global rule set that would be applicable uniformly for all types of agricultural operations. However, for the sake of the demonstrating the functions of the analyzer, a rule set depicted in Figure 3.11 and stated in Table 3.4 has been built into the system. According to this set, an operation is

PAGE 82

71 INTERNAL REPORT r No GET AN 1 OPERATION FROM THE USER Yes MORE REPORTS ? rii CHARACTERIZE DELAYS No fstop) I BUILT-IN HEURISTICS L DELAYS IN OPERATION 9 Yes I USER'S SUPPLIED HEURISTICS OPERATION(S) TO

PAGE 83

72 SCHEDULED Actual START start Good Start and Good Finish Actual Finish SCHEDULED FINISH Actual Start Good Start and Bad Finish m Actual Finish f Bad Start and Good Finish Bad Start and Bad Finish Figure 3.11 Schematic representation of built-in heuristics for the Operations Analysis report of the Expert Analysis System

PAGE 84

73 Table 3.4 Rule set for qualifying delays in an operation based upon its actual start and finish times within its agronomical work window using the onethird heuristics. Conditions Decisions The operation starts within first one-third and finishes before last onethird of the operational work window. Good Start and Good Finish The operation starts within first one-third and finishes during last one-third time of the operational window. Good Start and Bad Finish The operation starts after first one-third and finishes before last one-third of the operational window. The operation starts after first one-third and finishes during last one-third of the operational window. Bad Start and Good Finish Bad Start and Bad Finish

PAGE 85

74 considered as delayed start if it commences after one-third of its agronomic window, and is characterized as delayed finish if it continues in the last one-third of the window. A second version of the analyzer permits the user to define the critical window within the agronomic window for each operation individually. Operation fs) to be analyzed The delay in an earlier operation on a field could holdup the start of the current operation. For such a situation, the system need to analyze the earlier operation either by itself or in combination with the current operation for identifying causes of delays in the current operation. This leads to three following combinations to be analyzed: 1) earlier operation only ("LastOpsOnly") , 2) current operation only ("CurrentOpsOnly") and 3) both operations ("BothOps") as shown in Figure 3.10. The system identifies such situations by looking at the actual completion of earlier operation and comparing it with the actual start of the current operation. Actual done area for the operation ("DoneArea") is also considered in making these decisions. Table 3.5 presents these criteria in the form of induction rules and Figure 3 . 12 shows some examples of converting the entries from this table into actual rules. The Example Rule 3 in Figure 3.12 states that the earlier operation (LastOpsOnly) need to be analyzed

PAGE 86

75 Exeunple Rule l (Entry No. l)

PAGE 87

76 Table 3.5 Induction table for developing rules for identifying the operation (s) to be analyzed for the delays in the current operation. No

PAGE 88

77 if the operation had delayed start, timely finish and it started immediately after completion of the earlier operation. Identification of problem The delays in an operation can be caused because of shorter working hours and/or low working capacity of the machinery utilized. The low machinery capacity can be further attributed to either low working speed and/or to its size in general. The system is designed to identify all these factors using the following procedure. 1) The system estimates average work hours for the operation and compares them with the recommended daily work hours stored in an expert file. The average work hours for an operation is calculated by dividing total work hours by number of its working days. The recommendation is made to increase the working hours during the period of agronomic window of the operation, if the average work hours are less than the recommended work hour for the operation type. 2) In case there is no possibility of increasing work hours for the operation, the system analyzes the implements associated with the operation (s) in order to identify their (implements) operational parameters for improving timeliness of the operation. The implement list(s) attached to the operation (s) being analyzed is (are) divided into three sub-lists of different implements types namely self-propelled, perfectly-matched and

PAGE 89

78 under-sized implements. The self-propelled implements have their own built-in power source. On the other hand the perfectly-matched and under-sized implements are those which need a separate power unit for their operation. An implement is considered as a perfect match to a power unit if the power available from the unit almost equals the power required by the implement. The implement is classified as perfect match to a list of power units if more than 50% of the power units have perfect match to the implement individually. The implements which fail to meet these tests are classified as under-sized implements. Development of recommendations The system makes one or more of the following recommendations in order to reduce the delays in an operation: 1) Increase working hours during the operation window, 2) Increase speed of operation or working width of undersized implements, 3) Increase operational capacity of self-propelled implements and 4) Increase operational capacity of perfectly matched implements. The system uses the following steps to develop the recommendations . 1) It identifies the operation (s) to be analyzed and their problems using the criteria discussed earlier.

PAGE 90

79 2) It recommends increasing daily work hours in case it is considered as a problem. Else, it analysis the implements associated with the operation and makes recommendations to adjust their operational parameters. For perfectly-matched implements, it recommends increasing the size of the implements and their associated power unit(s) . For the under-sized and self-propelled implements, the system compares the speed at which the implement is being operated to the recommended speed for the operation type. If it is lower than the recommended speed for the operation type, it recommends increasing it within allowable limits for the operation type. In case of under-sized implements, it calculates the possible increment in implement speed to match up its power units (not exceeding the recommended speed) and advises accordingly. Else, it recommends a bigger size implement and the associated power units, if applicable. For a single operation case ("CurrentOpsOnly" and "LastOpsOnly", Table 3.5), it is either a "WrkHrsProb" or "ImpProb" (Table 3.6a). However, for both operations case ("BothOps", Table 3.5), it could be any combination of the two types of problems (Table 3.6b). The expert analyzer can handle all these situations.

PAGE 91

80 Table 3.6a Induction table for identifying the actual problem (s) with the operation (s) to be analyzed for the delays in the current operation, a) case of one operation being analyzed, b) case of both operations (current and previous operations being analyzed) Condition FurtherAction AvgWrkHrs=WrkHrsReco "ImpProb" Table 3.6b Induction table for identifying the actual problem (s) with the operation (s) to be analyzed for the delays in the current operation, a) case of one operation being analyzed, b) case of both operations (current and previous operations being analyzed) Current Operation Last Operation FurtherAction AvgWrkHrs=WrkReco AvgWrkHrs=WrkReco CurOpsWrkHrsLastOpsImp AvgWrkHr>WrkReco AvgWrkHrs>=WrkReco ImpBoth Where AvgWrkHrsCalculated average work hours for the operation WrkRecoRecommended work hours for the operation WrkHrsBothRecommend increased work hours for both operations CurOpsImpLastOpsWrkHrsCheck implement list for the current operation and recommend increased work hours for the last operation CurOpsWrkHrsLastOpsImpRecommend increased work hours for the current operation and check implement list for the last operation WrkHrsProbWork hours problem for the operation being analyzed and recommend increasing them ImpProbProblem with implement used for the operation, check the implement list of the operation being analyzed

PAGE 92

81 Execution procedure The two versions of the analyzer (with a built-in heuristics and user-supplied heuristic) make the same types of recommendations and use similar development process with slightly different execution procedures. The analyzer with the built-in heuristics automatically studies all the operations carried out by the simulation model and separates those which are considered having delays in their start and/or completion. It identifies the causes for the delays and remedies to overcome them, and stores this information in a separate file for presentation of the reports . The reports are presented using the screen layout shown in Figure 3.13. The user selects the field, the crop and the operation from the pop-up menus for which he wants the system's analysis and recommendations. The report and the recommendations are then presented in the lower half of the screen (Figure 3.13) which contains 1) Problem type, 2) Operation (s) analyzed for the delays, 3) Possible remedies. The second version of the analyzer carries out its execution in following steps. 1) Similar to version 1, it lets the user select the crop, the field and the operation, for which he wants the analysis. 2) It presents to the user the agronomic work window of the selected combination.

PAGE 93

82 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Expert Advisor-Operations Analysis Report * **************************************************** Press to Select Items of Farm Objects Field ^^^^ Crop ^^^^^^^ Operation ^ OPERATIONS ANALYSIS REPORT Figure 3.13 Screen layout for the Operations Analysis report with the built-in heuristics.

PAGE 94

83 3) It gets the heuristic from the user to characterize the delays. 4) It then analyzes the operation based upon the supplied heuristics and presents the user with the reports using the steps discussed for earlier version of the analyzer with built-in heuristics. The modified screen layout utilized for second version of the analyzer is presented in Figure 3.14. Machinery Usage Report In an operational farm system, the machinery and labor constitutes a major component of the capital outlay in the production cost of different crops. Farm managers attempt to make maximum utilization of the available machinery (tractors and implements) and labor on the farm to keep production cost low without sacrificing the product quality. They can increase the utilization level of this valuable resource-base by increasing the cultivated area, adjusting and changing the crop mixes or by withdrawing under-utilized machinery and labor from their farm. This report analyzes the usage of machinery and labor for the given farm system based upon the work report of the operations simulation. It also identifies the least utilized item for an object-class and analyzes its usage and allocation strategies in order to withdraw it from the farm, if possible. The criteria utilized for recommending withdrawal of an

PAGE 95

84 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Expert Advisor-Operations Analysis Report * **************************************************** Press to Selectltems of Farm Objects Work Windows Initially Supplied Operation Considered Delayed If Earliest Start Month Date Start After Latest Finish Month Date Finish After SSSWsSk Figure 3.14 Screen layout for the Operations Analysis report with the user-supplied heuristics.

PAGE 96

85 object-item, and development and execution process of the report follow. Criteria for withdrawal In addition to an overall utilization of an object-item, the decision to withdraw it from the farm could depend upon factors such as the importance of the item for the farm, and the effect of its withdrawal on other items of the same object-class. In addition, every farm could also have a minimum acceptable utilization level of a machinery unit not to warrant its withdrawal. Many commercial farms own machinery (both implements and tractors) more than what they generally require to complete their operations timely and efficiently during a normal year of cropping season. However, extra pieces of equipment are maintained to serve as a backups to most needed machinery to meet unwarranted situations for critical operations. The present analysis system recommends withdrawal of an item if it is utilized less than 20% of the maximum utilized item of the same object-class as detailed in Figure 3.15a. If the 20% test condition succeeds, the second level search is made for the object-item in different knowledge-bases (Table 3.7) to evaluate its importance for the current farming system. The search aims to find out the total number of places the object-item, being considered for withdrawal, appears as a possible candidate for any work. This number is

PAGE 97

86 Rule 1 IF Amt of Most Util Item = Amt. of Least Util Item THEN Recommend not to withdraw the Least Utilized Item, BECAUSE Farm has only one item of this type, OR Items are being utilized evenly. Rule 2 IF Amt of Least Util Item =0.0 THEN Recommend to withdraw of the Item, BECAUSE Farm is not using this Item at all. Rule 3 IF Amt of Least Util Item>=0.20*Amt of Most Util Item, THEN Recommend not to withdraw of the item, BECAUSE Farm has its reasonably balanced usage. Rule 4 IF Amt of Least Util ltem<0. 20*Amt of Most Util Items, AND Amount of Least Utilized Item >0.0, THEN Go for Further Analysis. Amt=Amount Util=Utilized Figure 3 . 15a Rules for recommending withdrawal of the least utilized item of farm objects (machinery and labor) . a) based upon the actual utilization of the items of farm object class, b) based upon the allocation strategy for the least utilized item.

PAGE 98

87 Table 3.7 Knowledge-bases searched for different objectclasses to find out the number of places the item appears as possible candidate for a job on the farm. Entity Type Knowledge-bases searched Implements (All Types) Tractors Operators Operations Implement Tractors, Implement and Irrigation Equipment

PAGE 99

88 further divided into 1) number of places it appears as a unique candidate for the job and 2) number of places it has one or more complementary units which could assume the task of the least utilized object-item after its withdrawal. Based upon the second level search, the rule set presented in Figure 3 . 15b decides and recommends for the withdrawal, if appropriate. Development and execution process The report is prepared utilizing the work report for the operations simulation and the other information related to the object-item supplied by the user. The system separates entries from the work report for the selected object-class. Actual work hours and days worked in by different items of the object-class are added to find out their seasonal utilization. The utilization levels, both in terms of working hours and work days, of the least and the most utilized object-items are then categorized up on a monthly basis. The seasonal work report of the least and the most utilized object-items is presented to the user to give him a global idea about their performance. The user can also assess the monthly breakup of utilization of these items, if he desires, in order to study the variation in their usage over the cropping season. Finally, the system analyzes and presents its report on the least utilized item of the selected object-class.

PAGE 100

89 Rule 5 IF NumCom=0 . , AND NumUnq = NumTot, THEN Recommend not to withdraw the Item, BECAUSE Item is allocated alone everywhere, AND It has no complimentary unit on farm. Rule 6 IF NumCom=NumTot , AND NumUnq = 0.0, THEN Recommend strongly to withdraw the Item, BECAUSE Item has a complimentary unit everywhere it is allocated. Rule 7 IF NumCom>=0 . 50*NumTot , THEN Recommend to withdraw the Item, BECAUSE More than 50% times the Item has a complimentary unit. Rule 8 IF NumCom<0.50*NumTot, THEN Recommend not to withdraw the Item, BECAUSE Less than 50% times the Item has a complimentary unit. Figure 3.15b Rules for recommending withdrawal of the least utilized item of farm objects (machinery and labor) . a) based upon the actual utilization of the items of an object class, b) based upon the allocation strategy for the least utilized item. NumTot= Total number of places the item appears as a possible candidate for a job. NumUnq= Number of places the item appears as a unique candidate for a job. NumCom= Number of places the item has at least one complimentary unit which can be utilized for the job if the item being analyzed is not available

PAGE 101

90 In the execution of this report, the user is asked to select the object-class such as Tractor, Laborers, or Implements through a pop-up menu. In the case of Implements, he is asked to make second choice for the implement type class such as land preparation, planting, harvesting, etc. On the final selection of the object-class, the system goes through the preparation and presentation of the reports. The system prepares and guards information for all the stages of the report. However, the user is not obliged to go through all of them. He can quit the advisor at any stage he wants to make changes in the farm resource-base. In making these changes, the user can use the recommendation of the expert system or his own experience. Accumulated Work Report This report works as a support to the earlier two reports: Operations Analysis and Machinery Usage reports. The user can utilize it to get additional details to further analyze the recommendations made by these reports and/or to get information about the items not covered by either of them. This report does not make any specific recommendations for the selected combination of object-items of the object-classes. However, its contents facilitate the user making management and planning decisions.

PAGE 102

91 Development and execution process The report is prepared utilizing the work report of the operations simulation. The user selects object-items for different farm object-classes such as crop, field, tractor, implement, etc. and the time interval for the report through pop-up menus on the screen layout presented in Figure 3.16. He can select one or all items from an object-class. On the selection of different object-items, the accumulator separates all the entries from the simulation report for the selected combination of object-items over the desired period. It then adds up the work hours and work days of the separated entries and prepares and presents two reports . The first report, in a concise format, consists of dates of actual start and finish of the usage of the selected object-items, total accumulated work hours, number of days actually worked, average daily work hours, average monthly work hours and list of the months during which the selected items actually worked. The second report, in a detailed format, consists of a complete listing of selected entries from the simulation work report on the daily basis over the desired time period. The concise report is automatically presented on the lower half of the screen (Figure 3.16), however the presentation of the detailed report is optional and the user can by-pass it, if he so desires.

PAGE 103

92 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Expert Advisor-Accumulated Work Report * Press to Select Duration of the Report Start Month Finish Month Write in Date and Press Start Date Finish Date Press to Select Items of Farm Obiects Crop ^^^^^ Field ^^^^^^^ Operation Figure 3.16 Screen layout for the Accumulated Work Report.

PAGE 104

93 Knowledge-Based Yield Estimation The ultimate goal of a farm system with crop production activities is to produce crops, either for the market and/or for home consumption (Figure 3.3). The factors which most influence crop yields can be broadly classified into natural resource factors (soil types, climate, etc.) and management factors (crop varietal selection, irrigation and fertilization levels and timings of critical operations) . Farmers have little control on natural resource factors. However, farm productivity can be greatly improved by appropriate selection of management factors and their timely implementation. Farmers can benefit significantly with timeliness of critical operations in a crop production process. One of the important factors which controls the timeliness of field operations is the machinery and labor availability on the farm. Farmers want to maintain an appropriate size and mix of machinery to complete their operations on time and economically. They neither want to be over-equipped with machinery which increases their fixed costs, nor do they want to be in short supply of equipment which could delay their critical operations and drastically reduce their crop yields and profits. They also want to know how an addition of a particular implement would alter the timeliness of different operations and would influence the crop yields and overall farm production and profits.

PAGE 105

94 A knowledge-based yield estimation system which appraises the farm production of different crops and their gross and net returns has also been developed and integrated with the farm decision system. The yield assessments for different fields are based upon the user supplied management inputs such as crop variety, irrigation and fertilization levels and simulated timings of different operations on an individual field. These yield values for different fields are then converted into the overall farm production and profit based upon the cost of production and expected sale price for different crops. The user can utilize this system, as demonstrated in chapter IV, to assess overall production, net and gross returns from his farm under his current farming system and to study the effect of variation in sale prices of different produce on his overall net returns. In combination with the operations simulation, the yield estimation system can also be utilized to study the effects of various machinery management decisions (daily work hours, machinery size and their working speed) on the timings of different operations and their influence on farm production and profit. The yield estimation system is structured in two components: crop yield knowledge-base (s) and an expert search system. The crop yield knowledge-bases can be developed using the crop growth models, acquiring knowledge from regional crop experts or from any other source available in the region.

PAGE 106

95 The expert search system is a PROLOG program. It collects crop related management input factors from the usersupplied field file and dates of critical operations from the simulation reports for each field and searches through the crop yield knowledge-bases to find the yield levels for the crops grown on different fields. The overall production for a field is then calculated by multiplying the yield times its harvested area. Crop Yield Knowledge-Bases The crop yield knowledge-bases are the relational tables of the input factors (both natural resource and management) and the expected yields for different crops. They are stored in the form of dynamic databases of PROLOG. The general format along with some hypothetical examples of these tables is presented in Appendix I. To demonstrate the functioning of the estimation system, a set of these tables for soybeans, peanut and wheat were developed using IBSNAT crop growth simulation models (IBSNAT, 1987) . A set of input values required as input for the models, and presented in Table 3.8 were selected from their respective databases. These values were chosen to approximately represent the test farm situation. The agronomic work window for planting for each crop was divided into weekly intervals. Simulation runs of the models were then made using the selected values of input factors and

PAGE 107

96 Table 3 . 8 Values of input parameters selected for running crop models for developing hypothetical crop yield knowledge-bases Parameter Value selected Weather year (s) Soil Type Crop Variety Soybean Wheat Peanut Tallahassee (FL) , 1954 (Considered as dry and also used for operations simulation) Milhopper Fine Sand Bragg Condo Florunner middle date for each week within agronomic work window for planting for each crop. These runs were made using batch files specially made for each model. A single line output for each run consisting of input parameters and the crop yield and its components were saved in a separate file for every crop. These output files then served as induction tables for developing the required knowledge-bases in the form of dynamic databases. The cotton yield values, to complete the knowledge-bases for all crops of the test farm, were then estimated on a hypothetical crop yield distribution curve (Figure 3.17). In this distribution a linear decrease in yield was assumed with delayed planting after first two weeks of the agronomic work window.

PAGE 108

97 Expert Search System This system searches through the crop yield knowledge-bases to estimate the crop yields for different fields on the farm. It can be used to get report for a single crop grown on different fields, for a single field (both or any one crop) or for the whole farm with all fields and crops. The screen layout which allows the user select choices about the field (s) and crop(s) through pop-up menus is presented in Figure 3.18. The flow pattern of the functioning of the system is depicted in Figure 3.19. Similar to expert analysis system, it also works in a repetitive mode and the user can utilize it to get reports for different combinations of fields and crops for the selected farm. Table 3.9 presents Table 3.9. Type of reports produced with different combination of selected entities Selection Type of Report Field Crop One Field One Crop One crop grown on the selected field One Field All Crops All crops grown on the selected field All Fields One Crop One crop grown on all farm fields All Fields All Crops All crops grown on all farm fields

PAGE 109

98 0.800 Yield (T/ha) .700 .600 20 21 22 Planting Weeks Figure 3 . 17 Hypothetical yield distribution of cotton crop as affected by its planting weeks.

PAGE 110

99 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Crop Yield and Profit Estimator * **************************************************** Press to Select Items of Farm Objects Figure 3 . 18 Screen layout for presenting Yield Estimation Report

PAGE 111

100

PAGE 112

101 the types of reports produced with different combinations of the selected object-items from the menus. The total production, cost, gross and net returns for a crop produced on a field are estimated using following equations. P = Y * HA (1) GR = P * SP (2) TC = AA * PC (3) NR = GR TC (4) ANR = NR/CA (5) where P = Total Production (Ton) Y = Yield (Tons/ha) HA = Harvested Area (ha) GR = Gross Returns ($) SP = Expected Sale Price ($/Ton) TC = Total Cost ($) AA = Average Area = (HA+CA)/2.0 NR = Net Returns ($) ANR = Average Net Return ($/ha) CA = Cultivated Area PC = Production Cost ($/ha) The average production cost and expected sale price for the crop is supplied by the user. The Average Area (AA) for estimating total production cost accounts for the situations where machinery constraints result in harvested area less than the cultivated area of a field. The report generated by the expert search system contains field name, its cultivated and harvested areas, crop name(s), weather set, yield, production, sale price, cost

PAGE 113

102 price, total sale, total cost, net profit and net profit per unit area for each field and for complete farm. An Intelligent Information Management System Information management deals with control of inflow and outflow of information, while assuring its adequacy and accuracy (Walton, 1967) . A good and intelligent information management acquires great rewards for an enterprise whereas mismanagement of information carries the threat of very high penalties. In large industrial enterprises specialists, referred to as Information Managers, are hired to carry out this task. A software-based information management system for large and complex simulation models can increase their ease of operation and also their credibility as decision-aid tools. It can help to collect knowledge, needed as an input for the model, from the user and let him update it in a friendly and interactive manner. The simulation model, discussed earlier in this chapter, requires a huge amount of farm specific knowledge in a predefined format for its functioning. A conventional procedural program with input data files would require a good amount of planning, organizational skill and typing ability on the part of the user to provide the model with the needed knowledge even for a small farming enterprise. The complexity of the task increases manyfold if one is required to manage

PAGE 114

103 a large enterprise comprising many farms with different types of cropping systems. A software-based information management system was designed and implemented. It is currently structured to collect farm information and works as an intelligent interface between the user and a field operations simulation model. Object-items of an operational farm system can be classified into two categories namely 1) physical object-class and 2) abstract object-class (Table 3.10). The details about each farm object-class are stored in separate files and are discussed later in this chapter. Items of a physical object-class can be numbered from 1 to "n", where "n" is the total number of items of the objectclass available on the farm. The typical examples are tractors, implements and fields. The items of these objectclasses are shared by other farm object-items. For example, Tractor_2 could be shared by five different implements to carry out seven types of operations on ten different fields. Items of an abstract object-class are not numbered. They do not exist physically on the farm. Unlike physical objectitems, they cannot be shared by other farm object-items. A typical example of this object-class is the operations list associated with a crop. This list is specific to a crop and cannot be shared by other crops. The planting operation, as an example, for different crops could have totally different requirements in terms of their timings and implement list.

PAGE 115

104 Table 3.10 Categorization of different farm object-classes Category Object-class Physical objects laborers, tractors, implements, equipments, crops and fields Abstract objects operations In addition, the objects of an operational farm system are inter-dependent on each other (Figure 3.5). For example, an operator is needed to make a tractor operational, and a tractor is needed to make an implement work in the field as explained earlier in this chapter. Therefore, development of a new set or updating information of an existing object-class file would require information from other related files. It could also require adjustments to one or more farm files to make the changes effective. Table 3.11 presents the files required to carry out different actions on various farm object-classes. For instance, the action to "add New Item" or to "modify An Item" in the tractor file would require information from farm and labor files, in addition to tractor file itself. Therefore, all these files should be present and should be accessible to the system in order to carry out these actions. Table 3.12 presents the listing of files affected by different updating options on various farm files. For example, an addition of a new laborer on the farm would not

PAGE 116

105 Table 3.11 List of files needed to carry out different actions on various farm objects files. File

PAGE 117

106 Table 3.

PAGE 118

107 Table 3.12 List of affected files due to various updating options of different farm objects files. File Name Action Performed Affected Files Names farm farm farm farm delete An Item add New Item modify An Item develop New Set all files deleted action not allowed field Action Not Allowed labor

PAGE 119

108 be effective until the changes in tractor, implement and equipment files are made to allocate the new laborer to different tractors and implements. Characteristics The principal characteristics of an Intelligent Information Management System for a farming enterprise with the crop production as principal activity can be listed as follows. 1) It should be able to adopt itself to the size and the complexity of a variety of farm systems from different locations. 2) It should be very friendly and interact with the user through menus requiring him to do a minimum amount of typing. 3) It should be able to store information about many farms to manage them individually whenever required. The information stored should be accessible to other components of the decision support system such as Operations Simulator, Yield Estimator, and Expert Advisor described earlier in the chapter. 4) It should work for developing a completely new farm set, as well as for updating the information about existing farms by modification, addition and deletion of an entry from different object-class files. It should prohibit the user from making duplicate entries of the same object-item.

PAGE 120

109 5) It should carry out various integrity checks such as cultivated area vs. total area, matching implement power requirement to power available from the power source, etc. during development and updating of farm knowledge. 6) It should be able to decide and collect the information needed to complete different types of machinery set such as self-propelled and the implements needing a separate power unit. 7) The same information should not be asked repeatedly. The information once supplied should be presented to the user, whenever it is a possible selection as an input henceforth. 8) It should keep track of the status of different farm files as affected by any change in the related file(s) and should advise the user accordingly. Components and their Functions An information management system with the above characteristics was designed and implemented in Turbo PROLOG and is named as Information Manager. It consists of two components: 1) Information Generator and 2) Information Modifier. Information Generator lets the user develop information for a completely new farm in a predefined logical sequence. The user fills in information on the specially designed forms on the computer screen. Once any information such as tractor make or model is entered, it need not be typed in again, as it will appear on a pop-up menu the next time

PAGE 121

110 when it is a possible selection as an input, thus saving many typing errors. The information collected is then stored in different files. Information Modifier lets the user update information about the existing farms. It permits him to access any farm file in a developed set and make changes such as addition, deletion of an object-item, or modification of one or more of its attributes in its object-class. The general decision tree of the Information Manager is depicted in Figure 3.20 and is discussed briefly hereafter. Information Generator Information Generator lets the user develop information about different farm object-classes of a new farm. It creates separate files for each class with the extension code supplied by the user. The sequence of collecting information for different object-classes is logically structured. The most needed information is collected first. On the successful completion of the general farm file, the name of the new farm with its extension code is registered with a built-in file manager. On the next usage of Information Manager, the name of the new farm shows up in the menu of farms' name to allow the user to update its information, if he so desires. On initiation of Information Manager, the user is given options to select a farm from a pop-up menu which also

PAGE 122

Ill INFO MANAGER NEW FARM I DEVELOP NEW SET I FARM LABOR TRACTOR IMPLEMENT EQUIPMENT CROPS FIELDS OPERATIONS I EXISTING FARM I MODIFY EXISTING SET -[farI^ MACHINERY CROPS FIELDS LABOR TRACTORS IMPLEMENTS IRRI. EQUIPMENT OPERATIONS' LIST ALL ITEMS DELETE AN ITEM ADD AN ITEM MODIFY AN ITEM DEVELOP NEW SET Figure 3.20 Flow chart of functioning of Information Management System

PAGE 123

112 includes "NewFarm" in addition to the already existing farms. The selection of "NewFarm" leads the user to Information Generator where he can develop information about different objects of his farm. The general farm information (name, location, etc) is developed first followed by labor, tractor, implement, irrigation equipment, crop, field and operation. The development process, in general, of a new farm information involves asking the user for the number of items of the object-class he possesses on his farm. The Information Generator then interacts with the user to collect information about each of them. The "operation" is an abstract object-class (Table 3.10) and its development is controlled internally by the system. In developing the operation file, the user is directly presented with the screen to enter its details rather than asking for their total number as in case of physical objectclasses. The development of the operations file is controlled by the crop file which has a list of operations for each crop. The system picks the first crop from the crop file and obtains details about all the operations present in its list. This process is then repeated for all the crops in the crop file. Information Modifier Information Modifier provides five options: list all items, delete an item, add new item, modify an item, and develop new set for updating knowledge about existing farms.

PAGE 124

113 List all items lists all items for the selected objectclass with their attributes on the screen. The user can examine them to decide his further action. Delete an item allows the user to withdraw one objectitem from its class at a time. In order to withdraw more items, the action should be repeated that many times. The user selects the object-item to delete from the menu of the object-class. Add new item allows the user to add one more item to its existing object-class file at a time. The process involves counting number of object-items in the class, allocating an identification number for the new item and receiving and saving its details. Modify an item allows the user to change one or more attributes of an item an object-class. The process involves letting the user make selection of the object-item, presenting him old attributes of the selected item, letting him make modifications and saving the item with the new attributes. Develop a new set allows the user to develop an entirely new set for any farm object-class. The process involves letting the user select the object-class, receiving number of items of the selected class, then collecting and saving information about each item of the object-class. On selecting one of an already existing farm, the user is led into Information Modifier where he is presented with a menu of different object-classes (farm, machinery, crop.

PAGE 125

114 field and operations) to let him select one to update information. The machinery is further subdivided into labor, tractor, implement and irrigation equipment. On selecting the object-class from this menu, the user is presented with updating options menu (Table 3.11, Figure 3.19). In updating existing information, the Information Modifier first verifies the status of the files needed to carry out the desired action (Table 3.11). In case of nonexistence of any of these files, it advises the user to develop them prior to carrying out the desired action. At this stage, the user is also informed of the effects of his action on other farm files (Table 3.12) and is warned that his updates would not be effective if he does not make changes in other affected files. It then brings the necessary files to memory, initializes screen layout, lets the user select a object-class and its item he would like to update, presents him the old information, if needed, then allows him to make changes in the selected object-item. Finally, it writes the file with updated information to the disk. Knowledge-Bases Utilized and Generated The knowledge manipulated by Information Manager can be broadly classified into a) knowledge utilized and b) knowledge generated by the user.

PAGE 126

115 The knowledge utilized consists of 1) type file, 2) screen layout files, 3) month details file, 4) manager file, and 5) expert file. The farm knowledge generated is stored in different files: 1) farm file, 2) labor file, 3) tractor file, 4) implement file, 5) irrigation equipment file, 6) crop file, 7) field file and 8) operation file. Appendix I presents a simplified version of these files for the Davis Farm located in Santa Rosa County of northwest Florida. This farm has been used as a test farm for operational evaluation and verification of the integrated decision support system. Knowledge utilized The general format of different databases utilized by Information Manager is presented in Table 3.13 and discussed briefly below. T ype file . This file consists of entries of a single database called "type." The database consists of two elements: 1) object-class name and 2) a list of object-items associated with the class. The list associated with certain object-classes can be modified by the user interactively. The typical example is crop and its varietal list. Appendix I gives the complete listing of this file for the test farm. This knowledge-base is utilized to prepare menus to let the user select object-items specific to his farm. The user

PAGE 127

116 Table 3.13 Format of PROLOG knowledge-bases of different files utilized by Information Management System to let the user generate farm knowledge File Name type file month file screen files manager expert Knowledge-bases and their format type (LandPrep Imp, [ "MBPlow" , "AddNewItem" , "DeleteAnltem"]) month ( "January" ,1,31) field ( "name" , str , 8,28,29) txtfield(8,12,12,"Name of Farm") windowsize(20,77) f ilesmanager ( "FarmName" , "FarmCode" , "Exist" , "Exist" , "Exist" , "Exist" , "Exist" , "Exist" , "Exist" , "NotExist" ) et( "October ",2.55) file cropirr("Peanuts","ClayLoam",10,200) soilchar("FineSand", 200. 0,120. 0,140.0) opcond ( "Soybean" , "LandPrep" ,[[0.0,3.0,1.0], [3.0,8.0,0.5]]) opstypedetail ( "LandPrepOps" ,8.0,7.5,7.0,0.76)

PAGE 128

117 can select a single item or a list of items depending upon the type of object-class. The selection for a variety of a crop to be grown on any field is a typical example of single object-item selection from a given list. On the other hand, selecting a list of tractors for an implement is a typical example of selecting a list from an existing list. An example of this database, presented in Table 3.13, signifies that Information Manager currently knows only "MBPlow" as a land preparation type implement. However it can be changed by selecting "AddNewItem" or "DeleteAnltem" from the pop-up menu. Screen layout files . These files are utilized for creating screen layouts for collecting information about different farm object-classes. There is a separate file for each class and is saved as "********. scr, " where the first word represents the name of the class such as farm, tractor, implement, etc. These files consist of entries of three databases and have been adapted from screen handler program of Turbo PROLOG ToolBox (Borland, 1987). Figures 3.21-3.28 present the screen layouts generated by these files. Appendix I gives the complete listing for collecting general farm information. Month file. This file contains entries of a single database with 3 elements namely month name, start Julian day

PAGE 129

118 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-General Farm Information * **************************************************** Action Being Performed Farm Name Location Total Area (ha) Cultivated Area (ha) Press to Select Activity Farm Generally Known As (3-Letters Only) Figure 3.21 Screen layout for collecting general farm information * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Laborers Information * **************************************************** Action Being Performed Farm Name ^^^^^^^^^^^^ Location Total Number of Farm Laborers Supplying Information about ?-r"»»r"»iocooocC'»;-o-*-?c-?o Name (One Word Only, such as JoeSmith) Principal Function (Type in for your own information) Figure 3.22 Screen layout for collecting farm laborers information

PAGE 130

119 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Tractors Information * **************************************************** Action Being Performed Farm Name Total Number of Tractors on the Farm Supplying Information about Make and Model ^^^^^^^ Horse Power (HP)^P (One Word Only, such as JohnDeer3340) Press to Select Operator's List and "End" to Finish the List Figure 3.23 Screen layout for collecting farm tractors information * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Implements Information * **************************************************** Action Being Performed Farm Name Total Numbers Press to Select General Classification Press to Select Specific Implement Name Press to Select Power Unit (sj[ and '| End'] to Finish the List Please Type in the Values and to Make^^Checks Work Speed (Km/hr) ^^^^ Working Width (m) Figure 3.24 Screen layout for collecting farm implements information

PAGE 131

120 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Irrigation Equipment * ********************************************ie******* Action Being Performed Farm Name Total Number of Irrigation Equipment Supplying Information about Make and Model ^^^^^^^M Capacity (ha-cm/hr): (One Word Only, such as CenterPivot40) Press to Select Operator's List and "End" to Finish the List ^^^^ Figure 3.25 Screen layout for collecting irrigation equipment information * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Crops Information * **************************************************** Farm Name ^^^^^^^^^ Total Crop Numbers Supplyin£_Inforaati^^^^^ Press to Select a about Crop PresstoSelectOperations and "End" to Finish Land Preparation Operations Plant and Ferti Application Operations Plant Protection Operations Harvesting Operations ^^'z'z'z'z-z-z'Z'Z'zVz'^'z^'i'z'^z'z%i'z^-Zri'^^ Figure 3.26 Screen layout for collecting farm crops information

PAGE 132

121 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Farm Fields Information * **************************************************** Farm Name ^^^^^^Cult. Area (ha )^^No. of Fields ^^ Supply ing_Info .F4.*lA.4..N.^J?i?.... .?'A®A.4...^.^.®^...(?>.? ) about PresstoSelect PresstoSelect Soil Type Irrigation Type Irri. Equipment Supply Crop(s) Related Information 1. Pressto Select PresstoSelect Crop Variety Days FertilizProduSale Name Name to ation ction Price Mature TYpe^Cost($/ha) ($/TonO 2.: Figure 3.27 Screen layout for collecting farm fields information

PAGE 133

122 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Farm Info Manager-Field Operations Information * **************************************************** Action Being Performed Farm Name Supplying Info about an Operation for Crop Operation Type Operation Name EarliestStartTime j^Press Supply Date and to Select Month) Press LatestFinishTime to Select Month) L?.?.®?.?."^.?J}.^.f-?.-^ Supply Date and Press W^ PresstoSelect ImplementList and "End" to Finish Figure 3.28 Screen layout for collecting field operations information

PAGE 134

123 and last Julian day. This database is utilized to check the validity of date entered by the user for any month as well as to convert Julian day to calendar month and date and vice versa . A typical format of this database in Table 3.13 signifies that the first and the last Julian day for the month of January are 1 and 31 respectively. Manager file . This file consists of entries of a single database named "fileManager. " It has only one entry to start with. The other entries are automatically added on after the successful completion of the development of the general farm file of the new farms. It keeps track of the status ("Exist"/"NotExist") of different files of the farms available to the system. This database consists of 10 elements: farm name, farm code and status of eight object-class files (farm, labor, etc.). This file is used to prepare the menu of farm names for letting the user select a farm with which he wants to work. Expert Knowledge File . This file contains expert knowledge which can be acquired either from the regional experts and/or from the published literature. It stores entries for five databases namely "cropirr", "soilchar", "opcond", "et" and "opstypedetail. " The "cropirr" contains information about the irrigation requirement for various crops when grown on different soil

PAGE 135

124 types. It consists of four elements: crop name, soil type, the amount and number of irrigations that could be applied during the crop cycle. The database "soilchar" contains soil moisture characteristics of different soil types with four elements: soil type, maximum water holding capacity, wilting point, and the threshold limit to start irrigation. The database "et" of two elements stores daily average evapo-transpiration values for different months of the year. The "opscond" database stores knowledge for developing rules to estimate daily working hours for different operations. This database consists of three elements: crop name, operation type and a set of lists of real numbers which is used to estimate actual working hours for the day. Figure 3.29 presents an example of using this database for developing the rule set for actual work hours based upon the rainfall and scheduled work hours for the day. The "opstypedetail" database consists of five elements to provide operational details for different operation types. These elements are operation type and its upper allowable limits for the recommended daily work hours, draft requirement and the speed of operation. This knowledge is used to conduct various types of consistency checks on the information supplied by the user.

PAGE 136

125 General format opcond ( Crop , SoilType , OpsType , ListOfListOfRealNumbers) Specific exeunple opcond ( "Soybean" , "Sand" , "LandPrep" , [[R1,R2,1.0] , [R2,R3,0.5]] Rulel IF rainfall > Rl mm for the day AND rainfall <= R2 mm for the day THEN do 100% of scheduled work hrs Rule_2 IF rainfall > R2 mm AND rainfall <= R3 nan AND schedule Work Hrs for the day are >4 . Hrs THEN do 50% of scheduled work hrs Rule_3 IF rainfall > R2 mm AND rainfall <= R3 mm AND Scheduled work Hrs <=4 . Hrs THEN do 100% of scheduled work hrs Rule_4 IF rainfall > R3 mm THEN don't do any work Figure 3.29 Rules for deciding actual work hours for the day based upon the operating conditions (ListOfListOfRealNumbers) of an operation type (OpsType) , rainfall and scheduled work hours for the day.

PAGE 137

126 For example. Information Manager identifies the inappropriate parameters for an implement in relation to its power sources. In case, the power requirement for an implement exceeds the power available from the smallest tractor selected for the implement, the user is prompted and advised to reduce either the speed or the working width of the implement. Knowledge developed by the user The knowledge developed by the user through Information Manager is stored in eight files of dynamic databases. The attributes of different farm object-classes and their typical format, as stored in the form of dynamic databases were discussed earlier in this chapter (Table 3.1 and Figure. 3.4) . The number of entries for the physical object-class files equals their numbers present on the farm. A brief description of the mechanism of developing information about different farm object-classes follows. Farm file . Most of the user supplied information on this screen is entered except for the principal activity which is selected from a pop-up menu. A built-in checker prevents the user to enter a cultivated area more than the total farm area. The updating options "add Mew Item" and "develop New Set" are not permitted on this file. However, the user can change cultivated area and/or total area using "modify An Item" option.

PAGE 138

127 Labor file . Most of the information is user entered. This file is utilized to generate the list of operators on the farm for allocating them to different farm implements, equipment and tractors. Tractor file . The make, model and horse power of the tractor are entered. The operators list is selected from a pop-up menu consisting of the laborers available on the farm. All updating options are permitted on this file. The user can modify the make, model, horse power and/or operators list associated with the tractor. This file is utilized to generate the list of tractors on the farm for allocating them to different implements. Implement file . The implement type, its name, and tractor/ operator list are selected from the pop up menus, and working speed and width are entered by the user. The pop-up menu of the implement names can be changed interactively by the user. The menu of tractors available on the farm also includes "NotNeeded" option which can be selected for the self-propelled and the manually operated implements. When "NotNeeded" is selected, the user is presented with another menu of laborers available on the farm, and then asked to select the operators list for the implement. All updating options are permitted on this file. The user can change operational parameters (working speed and working width) of the implements and the tractor/ operator list associated with it.

PAGE 139

128 This file is used to prepare the menu of implements to let the user select them (implements) for different operations while developing the operations database. Irrigation equipment file. The equipment specifications such as model and its capacity are entered by the user, and operators list is selected from a pop-up menu consisting of laborers available on the farm. The "NotNeeded" option is also available for the equipment requiring very nominal amount or no labor at all for its operation. All updating options are permitted on this file. The user can change the capacity and the operators list for the equipment. Crop file . Most of the information is collected by selecting object-items from the pop-up menus. The content of the crop menu for selecting crop(s) for the farm can be modified by the user to suit his specific requirements. The information for different operation types is collected separately and then joined together in a proper sequence to form an aggregate list for the crop. The user can select the sequence of operations of each type from the pop-up menus. He can even modify the content of the menus of the land preparation and the plant protection types of operations to include operations suiting to his farming practices for different crops and soil types. All updating options are permitted on this file. The user can change the sequence and content of the list of

PAGE 140

129 operations. This file is utilized to prepare a menu of crops for letting the user to select them for allocating to different fields. Field file . Most of the information is collected through the pop-up menus. The menu for selecting crops for the field also provides the option of "NoCrop" in case the user decides to grow only one or no crop at all on any field. Information Manager keeps track of the unaccounted cultivated area of the farm and prohibits the user from creating fields with total area more than the cultivated area of the farm. All updating options are permitted on this file. The user can change the crop and its characteristics, field area and its irrigation status. Operations file . Number of entries in this file equals the sum total of the items in lists of operations associated with different crops in the crop file. The agronomic work windows (earliest start time and latest finish time) and implement list are collected through pop-up menus. The user can and should select one or more implements for each operation in order to successfully simulate the operation as discussed earlier in this chapter. The updating options of "add New Item" and "delete an Item" are not allowed on this file. However, the user can modify agronomic work windows and the list of implements associated with an operation.

PAGE 141

CHAPTER IV TESTING AND EVALUATION The model testing and evaluation, in general, can be divided into verification and validation. Verification is a process by which programming logic is compared with the programmer's intentions. On the other hand validation deals with comparing the simulation results with the actual system's behavior. For knowledge-based systems, validation has been termed as "qualification." The integrated decision support system, named FARMSYS, combine the four components: Operations Simulator, Expert Analysis, Yield Estimation and Information Management Systems discussed in Chapter III. Testing and evaluation of FARMSYS has been carried out in two stages referred as professional qualification and operational verification. The prof essional qualification involved letting a team of peers evaluate and critique the competence of the system in terms of its knowledge, logic, functioning, user-interface, etc. in order to identify its strengths and weaknesses. The operational verification was aimed to demonstrate the functioning of FARMSYS on a real farm data and also to show how it can be utilized as a planning tool for machinery and labor for multicrop production systems. FARMSYS is operated using a pulldown menu of Turbo PROLOG Toolbox (Borland, 1987) . The 130

PAGE 142

131 schematic representation of the screen layout and the set of menus along with their final actions is depicted in Figure 4.1. On the selection of an option from the main menu (for example "Information Manager") , an executable file and other related information to that option are loaded to the computer memory. The user can then carry out the intended actions. When terminating the job the command is passed back to FARMSYS and the user can select the next option or can select "Quit" to return to DOS. This structure of FARMSYS has made it possible to manage more than 1200 K of executable files under the DOS environment with less than 640 K available memory. The time required to operate different components of FARMSYS depends upon the farm size and type of computer utilized. The system required approximately 45 minutes for one simulation run for the test farm (Davis farm) for two consecutive years on 12 Mhz IBM AT 80286 with 6 Mhz math coprocessor. The actions by other components such as Information Manager and Expert Analysis System are quick and interactive with little time delays. Professional Qualification For the professional level qualification a one-day miniconference on Knowledge-based Decision Systems using Logic Programming was organized at the Department of Agricultural Engineering of the University of Florida. It was attended by

PAGE 143

132 q: o co m I o o CO I CO Q. O

PAGE 144

133 10 experts from U.S. and two from other countries (Appendix II) , in addition to the local faculty members. The structure, components and logic of FARMSYS were presented to the participants in detail. The participants witnessed a demonstration of FARMSYS with a real farm example. The eight professionals specially invited for the qualification session were then asked to evaluate FARMSYS and its different components using a specially designed questionnaire (Appendix II) which contained statements concerning various features of FARMSYS. They had 5 options to select for each option ranging from "strongly agree" to "strongly disagree." They were also encouraged to identify FARMSYS weaknesses and strengths in comparison to other similar tools. The analysis of the questionnaire was carried out in two stages: structured response analysis and non-structured response analysis. In structured response analysis, the answers to different statements were analyzed by grouping and counting the similar responses. Tables 4.1 to 4.8 present these results. The actual comments made by the experts were grouped into four sub-headings: strengths, weaknesses, suggestions and concerns about FARMSYS as non-structured responses.

PAGE 145

134 Table 4.1 Responses to the questionnaire about qualification of the Information Management System of FARMSYS Responses

PAGE 146

135 Table 4.2 Responses to the questions about qualification of Operations Simulation System (Knowledge-bases) of FARMSYS Responses

PAGE 147

136 Table 4.3 Responses to the questions about qualification of Operations Simulation System (Simulation Methodology) of FARMSYS Responses

PAGE 148

137 Table 4.4 Responses to the cjuestions about qualification of Yield Estimation System of FARMSYS Responses

PAGE 149

138 Table 4.5 Responses to the questions about qualification of Expert Analysis System (Machinery Usage Report) of FARMS YS Responses Statements/ Quest ions' 12 3 Strongly agree 3 10 Agree 4 3 4 Undecided 111 Disagree 3 3 Strongly disagree No response Total 8 8 8 ". The numbers correspond to the following statements 1. The objective of the report is sufficiently strong and impressive and users will make intensive use of this report. 2. The criteria utilized for identifying the least utilized item are adequate and realistic. 3. The criteria utilized for deciding recommendation about least utilized item are adequate and realistic.

PAGE 150

139 Table 4.6 Responses to the questions about qualification of Expert Analysis System (Operations Analysis Report) of FARMS YS Responses

PAGE 151

140 Table 4.7 Responses to the questions about qualification of Expert Analysis System (Accumulated Work Report) of FARMS YS Responses

PAGE 152

141 Table 4.8 Responses to the questions about overall qualification of FARMSYS Responses

PAGE 153

142 Structured Response Analysis The analysis of the questionnaire suggested that all participants appreciated the general structure of FARMSYS and approach taken for its development. They had concern about the relevance of the some of the heuristics utilized in different components of FARMSYS for their global applicability. In general, all participants found the Information Management System qualified for receiving farm information in an interactive and friendly manner (Table 4.1). This was considered one of the strength of FARMSYS. There was some concern about the structuring and contents of different components of farm knowledge-bases (Table 4.2 and 4.3). However, mostly all participants found the contents of the reports produced by the simulation essential and adequately structured. They generally agreed that the facility of representing input knowledge using semantic nets has been able to capture the farm knowledge in a more realistic manner than conventional simulators and it has also made FARMSYS a versatile and flexible tool. However, they remained undecided or expressed their disagreement on the claim that FARMSYS checks conditions during simulation more rigorously than conventional simulators. The screen layout for letting the user select field (s) and crop(s), and the structure and contents of the reports

PAGE 154

143 produced by the Yield Estimation System received favorable rating (Table 4.4). However, they were undecided or had disagreement on its qualification to predict the farm yield. The three mini-expert systems (Machinery Usage, Operations Analysis and Accumulated Work Reports) of the Expert Analysis System were considered as important components of FARMSYS (Tables 4.5-4.7) . In general, they were considered qualified for their intended functions. However, some experts had concern about the applicability of built-in heuristics in these reports, specially the 20% criteria of Machinery Usage Report and the one-third rule for deciding "late" starts and finishes in the Operations Analysis Report. These comments led to further revisions in these reports which allow the user to specify the rules for late starts and finishes individually for each operation. Table 4.8 presents the overall evaluation of FARMSYS and its different components. This table indicates that 50% of the participants considered FARMSYS qualified as a decisionaid tool and another 25% were undecided. The Operations Simulator and the Information Management System are its (FARMSYS) strong components. The table also indicates that 50% of the participants were undecided about the qualification of the Expert Analysis System. It was mainly because of the built-in heuristics for characterizing delays in the operations for the Operation Analysis report and the 20% criteria for the Machinery Usage report.

PAGE 155

144 Insufficient time for a thorough presentation of FARMSYS and its different components at the one-day meeting probably accounts for some of the negative responses. However, some of these limitations have been already eliminated in the second version of the Operations Analysis report as discussed in Chapter III. The possible ways to implement some others are discussed in the plans for future work in the next chapter . Non-Structured Responses The non-structured responses mainly dealt with identifying strengths, weaknesses, suggestions and concerns about various components of FARMSYS. Some of the strengths of FARMSYS, identified by the experts (Appendix II) , are its comprehensive nature in machinery selection process for working in a field, its framework and structured approach, its ease of setting up and the flexibility of the produced reports. All these strengths can be mainly credited to the object-oriented and logic programming approach taken in its development. The experts also made some suggestions for improvements which are listed in Appendix II. These suggestions included incorporation of location specific rules for various reports, detailed economics for various operations, the possibility of

PAGE 156

145 including custom hiring of tractors and other machinery at peak periods and a facility to put more than one machine in the same field for the same operation. Role of Mini-Conference in Evaluating Knowledge-based Systems There is a general concern about the methodology for validating or qualifying knowledge-based systems. There are no standard procedures available for this purpose. Different authors (Khuri et al., 1988; Nguyen et al., 1987) have tried different approaches for validating or qualifying knowledge systems. The experiences with FARMSYS indicate that the methodology of a small group of experts meeting together to evaluate and critique the system offers a good and practical alternative for validation. However, it is recommended that such a meeting should occur as two half-day sessions instead of one full day as in the case of FARMSYS. The first half-day session, preferably during an afternoon should be devoted to explaining and demonstrating the system. During the latter part of the afternoon or that evening, the participants should be encouraged to use the system. The second half-day session, preferably during the morning hours of the next day, should be devoted to the experts filling out questionnaires or other related material regarding the qualification of the system.

PAGE 157

146 Operational Level Verification For the operational level verification, contacts were established with three fanners from north Florida through the regional extension agents. Visits were made to their farms and the knowledge about one of them (Davis Farm) was collected using the Information Management System. The Davis farm knowledge (Appendix I) was then utilized as an input to FARMSYS to test its functionality as a decision-aid tool. Additional input knowledge for operating FARMSYS was collected from either the published literature or was based upon estimates of experienced agricultural engineers. The actual weather data of Tallahassee, FL, for the years 1954 (Dry Year) , 1960 (Normal Year) and 1964 (Wet Year) were selected to make the test runs. The test runs are not intended to analyze any particular problem associated with the Davis farm. They are rather intended to show that FARMSYS actually performs as designed, how its different components can be utilized in an integrated form and types of problems it can address for a typical farm setting. Different components of FARMSYS work independently and can be utilized in any sequence the user desires. However, the test runs presented in this chapter were made utilizing different components of FARMSYS as depicted in Figure 4.2.

PAGE 158

147

PAGE 159

148 Description of the Test Farm The test farm consists of about 400 hectares of cultivated area allocated to 23 fields. It has 4 laborers, 5 tractors and 25 implements. It grows 4 crops (cotton, peanuts, soybeans and wheat) and has 10 types of cropping systems as listed in Table 4.9 followed on different fields. Each of these crops and cropping systems require a different number of operations, ranging from 6 for wheat to 16 for cotton, during their production cycles. Each operation has its specific requirements in terms of its agronomic work window and implement list. Each implement has its specific characteristics in terms of tractor or labor requirements and its working width and speed of operation. Setting up Farm Knowledge for Simulation Runs All the crops, except wheat, are planted and harvested during the same calendar year. Wheat is planted in the second half of a year and harvested early in the following year. This requires the program to run for two consecutive years in order to a simulate the complete cropping season of the farm. It also requires two years of weather input which were selected "Dry" after "Dry" year. The crops of the second year were suffixed by character "2" and the agronomic work windows of different operations for the second year were adjusted by adding 365 to their values of the first year.

PAGE 160

149 Table 4.9 Cultivated area and cropping systems of different fields on the Davis farm. Field Area (ha) Cropping System Field_l Field_2 Field_3 Field_4 Field_5 Field_6 Field_7 Field_8 Field_8 Field_9 Field 10 102.2

PAGE 161

150 It is possible to simulate the test farm with its 23 fields. However, for the sake of simplicity of reporting the results, the test runs reported in this chapter were made by grouping all the fields with same cropping system into one single field. This led to a total of 10 fields (Table 4.9) with the total cultivated area of the farm unchanged. The scheduled work hours is another factor which can be adjusted prior to the start of each simulation. It is done using the screen layout depicted in Figure 4.3. The initial test runs were made with six hours of daily scheduled work for all months of the year. This resulted in zero "done area" for many operations on different fields. Then eight hours of scheduled work per day for the entire year also resulted in unfinished work for certain operations. Finally, it was possible to complete all operations on all fields within their operational windows utilizing the daily scheduled work hours as presented in Table 4.10. These initial runs of simulation with FARMSYS showed that the Operations Simulation functioned properly, and they also showed the typical variation in requirements of work hours during different times of the cropping season. The results from the last run, referred as a "success run," are discussed in detail.

PAGE 162

151 * FARMSYS-A Decision Support System for Multi-Crop * * Production Systems * * Operations Simulator-Scheduled Work Hours * ****************************ie*********************** Selected Year of Simulation Month WorkHrs/Day Month January ^^^^^^ February March ^^^^^^ April September ^^^^^^ October ^^^^^^ December November WorkHrs/Day Figure 4.3 Screen layout for scheduling working hours for the Operations Simulation.

PAGE 163

152 Table 4.10 Scheduled work hours for different months for simulating field operations on Davis farm Month Scheduled Work Hours January 8 February 8 March 8 April 12 May 12 June 12 July 8 August 8 September 12 October 8 November 8 December 8

PAGE 164

153 Operations Simulation Reports The simulator produces three reports on field operations namely work report, no-work report and summary report. The examples of work and no-work reports for the success run produced by the simulator are presented in Figure 4.4. These examples indicate that on Julian day 100, the simulator tried to carry out five tasks on different fields. It successfully completed three of them and failed to carry out the other two. The tasks successfully completed (Work report) were 1) Plowing 14.2272 hectares on "Field_l" for "Cotton" with total cultivated area of 102.2 hectares using "BottomPlow, " "Tractor_l" and "Jerry" by working 12 hours; 2) Harrowing 30.26 hectares on "Field_2" for "Cotton" using "Disk Harrow," "Tractor_l" and "Keith" by working 12 hours and 3) Fertilize 27.907 hectares on "Field_4" for "Cotton" using "FeriSpreaderLP," "Tractor_4" and "Joe" by working 12 hours. The tasks to Fertilize on "Field_5" and "Field_8" of "Soybeans" were tried but could not be done because the machinery needed was not available ("MachinesNotAvail") . It required "FertiSpreaderLP" which was not available ("NotAvail") . It was being utilized for applying fertilization on "Field_4." The complete summary report of the success run is presented in Table 4.11. The table presents the scheduled work window (ScSt to ScFn) , actual work window (AcSt to AcFn) ,

PAGE 165

154 WorK Report General format workreport( julianDay, Month, Field, Crop, Operation, CultArea, Day's DoneArea, TotDoneArea, Implement, Operator, Tractor, ActWorkHr) For the Julian Day 100 workreport(100, "April", "Fieldl", "Cotton", "Plowing", 102.2, 14.2272, 14.2272, "BottomPlow" , "Jerry" , "Tractor_l" , 12 ) workreport(100, "April", "Field_2", "Cotton", "Harrowing", 76.8, 30.26016, 30.26016, "DiskHarrow", "Keith", "Tractor_2", 12) workreport(100, "April", "Field_4", "Cotton", "Fertilize", 41.6, 27.9072, 27.9072, "FertiSpreaderLP", "Joe", "Tractor_4" , 12) No Work Report General format noworkreport( julianDay, Month, Field, DoneArea, Crop, Operation, DoneArea, ReasonOfNoWork, ImplementList, AvailStatus, WhereAboutlmplementList, TractorList, AvailStatus, WhereAboutTractorList, OperatorList, AvailStatus, whereAboutOperatorList) For the Julian Day 100 noworkreport(100, "April", "Field_5", 79.6, "Soybeans", "Fertilize", 0, "MachinesNotAvail" , [ "FertiSpreaderLP" ] , "NotAvail" , [["FertiSpreaderLP", "field4", "Cotton", "Fertilize"]] , ["Tractor_4", "Tractor_5"] , "Avail", [], [ "Keith" , "Ray" , "Joe" , "Jerry" ] , "Avail" , [ ] ) noworkreport(100, "April", "Field_8", 11.8, "Soybeans", "Fertilize", 0, "MachinesNotAvail" , ["FertiSpreaderLP"] , "NotAvail", [ ["FertiSpreaderLP", "field4", "Cotton", "Fertilize"] ] , [ "Tractor_4" , "Tractor_5" ] , "Avail" , [ ] , [ "Keith" , "Ray" , "Joe" , "Jerry" ] , "Avail" , [ ] ) Figure 4 . 4 Examples of work and no-work reports of the Operations Simulation of FARMSYS.

PAGE 166

155 Table 4.11 Summary report of the "success run" of the Operations Simulation for Davis farm (Appendix I) for the years "Dry" followed by "Dry" (1954) . ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_l (102.2 ha), First Year (Cotton) Fertilize 92 136 92 95 4 48.0 102.2 Harrowing 92 136 96 99 4 48.0 102.2 Plowing 92 151 100 108 8 90.0 102.2 1 Planting 106 161 109 112 4 48.0 102.2 Sprayingl 106 167 113 114 2 24.0 102.2 Cultivationl 116 172 116 120 5 60.0 102.2 Spraying2 122 182 122 123 2 18.0 102.2 Cultivation2 126 189 126 130 5 60.0 102.2 Spraying3 131 212 131 131 1 12.0 102.2 Cultivation3 167 212 167 172 6 60.0 102.2 FertiSpreading 167 212 173 181 5 60.0 102.2 4 Spraying4 167 223 182 183 2 20.0 102.2 Spraying5 172 243 184 184 1 8.0 102.2 Spraying6 183 244 186 186 1 8.0 102.2 1 Harvesting 259 350 262 275 13 152.0 102.2 1 Mowing 289 381 289 294 6 48.0 102.2 Field_l (102.2 ha), Second Year (Cotton) Fertilize 458 502 458 461 4 48.0 102.2 Harrowing 458 502 462 465 4 48.0 102.2 Plowing 458 507 466 474 8 90.0 102.2 1 Planting 472 533 475 478 4 48.0 102.2 Sprayingl 473 533 479 480 2 18.0 102.2 Cultivationl 473 538 481 485 5 60.0 102.2 Spraying2 477 548 486 487 2 24.0 102.2 Cultivation2 492 553 492 496 5 60.0 102.2 Spraying3 497 578 498 499 2 18.0 102.2 1 Cultivation3 533 578 533 537 5 54.0 102.2 FertiSpreading 533 580 538 546 5 60.0 102.2 4 Spraying4 533 578 547 547 1 12.0 102.2 Spraying5 538 609 548 548 1 8.0 102.2 Spraying6 548 610 549 549 1 8.0 102.2 Harvesting 625 716 628 642 14 156.0 102.2 1 Mowing 655 730 655 660 6 48.0 102.2 ScStEarliest Start Time ScFnLatest Finish Time AcStActual Start Time AcFnActual Finish Time WrkDysNo. of Days Worked WrkHrs-No.of Hours Worked WArea -Worked Area NoWrkDys-No. of No-Work Days R-Rain, M-Machinery

PAGE 167

156 Table 4 . 11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_2 (76.8 ha). First Year (Cotton) Fertilize 92 136 96 98 3 36.0 76.8 Harrowing 92 136 100 102 3 36.0 76.8 Plowing 92 151 110 118 6 72.0 76.8 Planting 106 161 121 124 4 42.0 76.8 Sprayingl 106 167 125 126 2 24.0 76.8 Cultivationl 116 172 127 130 4 48.0 76.8 Spraying2 122 182 131 133 2 18.0 76.8 1 Cultivation2 126 189 134 137 4 48.0 76.8 Spraying3 131 212 138 138 1 12.0 76.8 Cultivation3 167 212 173 180 4 48.0 76.8 4 FertiSpreading 167 212 182 187 5 44.0 76.8 1 Spraying4 167 223 188 189 2 16.0 76.8 Spraying5 172 243 190 191 2 12.0 76.8 Spraying6 183 244 192 192 1 8.0 76.8 Harvesting 259 350 276 291 15 120.0 76.8 1 Mowing 289 381 295 299 5 40.0 76.8 Field_2 (76.8 ha). Second Year (Wheat) Fertilize 289 350 299 305 5 40.0 76.8 2 Harrowing 289 350 306 310 5 36.0 76.8 Plowing 289 350 311 316 6 48.0 76.8 Planting 320 366 320 325 6 44.0 76.8 FertiSpreading 396 425 396 401 6 48.0 76.8 Harvesting 502 528 490 499 4 42.0 76.8 1 Field_3 (6 ha) , First Year (Cotton) Fertilize 92 136 99 99 1 12.0 6.0 Harrowing 92 136 104 104 1 12.0 6.0 1 Plowing 92 151 119 119 1 12.0 6.0 Planting 106 161 125 125 1 12.0 6.0 Sprayingl 106 167 134 134 1 12.0 6.0 Cultivationl 116 172 135 135 1 12.0 6.0 Spraying2 122 182 136 136 1 12.0 6.0 Cultivation2 126 189 137 137 1 12.0 6.0 Spraying3 131 212 138 138 1 12.0 6.0 Cultivation3 167 212 181 181 1 12.0 6.0 FertiSpreading 167 212 188 188 1 8.0 6.0 Spraying4 167 223 190 190 1 4.0 6.0 GO Spraying5 172 243 193 193 1 8.0 6.0 Spraying6 183 244 194 194 1 8.0 6.0 Harvesting 259 350 292 293 2 16.0 6.0 Mowing 289 381 300 300 1 8.0 6.0

PAGE 168

157 Table 4.11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_3 (6 ha) , Second Year (Soybeans2) Fertilize 458 502 462 462 1 12.0 6.0 Harrowing 458 502 466 466 1 12.0 6.0 Bedding 472 502 472 472 1 12.0 6.0 Planting 502 548 502 502 1 12.0 6.0 Cultivationl 502 563 503 503 1 12.0 6.0 Cultivation2 520 578 520 520 1 12.0 6.0 Cultivation3 549 589 549 549 1 8.0 6.0 Sprayingl 563 594 563 563 1 8.0 6.0 Spraying2 580 640 580 580 1 8.0 6.0 Harvesting 650 681 637 637 1 12.0 6.0 Field_4 (41.6 ha). First Year (Cotton) Fertilize 92 136 100 101 2 24.0 41.6 Harrowing 92 136 105 106 2 18.0 41.6 Plowing 92 151 120 124 3 36.0 41.6 Planting 106 161 131 138 3 30.0 41.6 1 Sprayingl 106 167 140 140 1 12.0 41.6 1 Cultivationl 116 172 141 142 2 24.0 41.6 Spraying2 122 182 143 143 1 12.0 41.6 Cultivation2 126 189 144 145 2 24.0 41.6 Spraying3 131 212 146 146 1 12.0 41.6 Cultivation3 167 212 182 184 3 28.0 41.6 FertiSpreading 167 212 189 192 4 28.0 41.6 Spraying4 167 223 193 193 1 8.0 41.6 Spraying5 172 243 195 195 1 8.0 41.6 Spraying6 183 244 196 196 1 8.0 41.6 Harvesting 259 350 294 303 8 64.0 41.6 2 Mowing 289 381 304 306 3 24.0 41.6 Field_4 (41.6 ha), Second Year (Peanut2 ) Fertilize 427 456 427 429 3 24.0 41.6 Harrowing 427 456 430 432 3 20.0 41.6 Plowing 427 456 433 437 5 40.0 41.6 Planting 472 487 472 473 2 24.0 41.6 Cultivationl 488 504 488 490 3 30.0 41.6 Sprayingl 488 502 491 491 1 12.0 41.6 Cultivation2 512 563 512 515 2 24.0 41.6 2 Spraying2 533 563 533 534 2 18.0 41.6 Spraying3 540 578 547 547 1 12.0 41.6 Spraying4 549 594 549 549 1 8.0 41.6 Spraying5 562 609 562 562 1 8.0 41.6 Harvesting 611 640 613 621 9 96.0 41.6

PAGE 169

158 Table 4 . 11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_5 (79.6 ha). First Year (Soybeans) Fertilize 92 136 102 105 3 36.0 79.6 1 1 Harrowing 92 136 107 110 3 36.0 79.6 Bedding 106 136 111 116 3 36.0 79.6 Planting 136 182 140 147 4 48.0 79.6 1 Cultivationl 145 197 150 153 4 48.0 79.6 2 Cultivation2 166 212 166 170 5 48.0 79.6 Cultivations 183 228 186 191 6 44.0 79.6 1 2 Sprayingl 197 228 197 197 1 8.0 79.6 Spraying2 214 274 214 214 1 8.0 79.6 Harvesting 284 315 282 287 6 48.0 79.6 Field_5 (79.6 ha). Second Year (Cotton2) Fertilize 458 502 463 465 3 36.0 79.6 Harrowing 458 502 467 470 3 36.0 79.6 1 Plowing 458 507 475 482 6 72.0 79.6 Planting 472 533 486 498 4 42.0 79.6 1 Sprayingl 473 533 500 501 2 24.0 79.6 Cultivationl 473 538 502 506 4 48.0 79.6 1 Spraying2 477 548 507 508 2 24.0 79.6 Cultivation2 492 553 509 512 4 48.0 79.6 Spraying3 497 578 515 516 2 24.0 79.6 2 Cultivations 533 578 538 545 4 48.0 79.6 4 FertiSpreading 533 580 547 552 5 44.0 79.6 1 Spraying4 533 578 553 553 1 8.0 79.6 Spraying5 538 609 554 554 1 8.0 79.6 Spraying6 548 610 555 556 2 12.0 79.6 Harvesting 625 716 648 662 15 120.0 79.6 Mowing 655 730 663 669 5 40.0 79.6 2 Field_6 (16.4 ha). First Year (Peanut) Fertilize 61 90 61 61 1 8.0 16.4 Harrowing 61 90 62 62 1 8.0 16.4 Plowing 61 90 63 64 2 16.0 16.4 Planting 106 121 106 107 2 18.0 16.4 Cultivationl 106 135 108 108 1 12.0 16.4 Sprayingl 106 131 109 109 1 12.0 16.4 Cultivation2 151 197 151 151 1 12.0 16.4 Spraying2 167 197 171 171 1 12.0 16.4 Sprayings 172 212 172 172 1 12.0 16.4 Spraying4 183 223 184 184 1 8.0 16.4 Spraying5 192 243 192 192 1 8.0 16.4 Harvesting 245 274 247 250 4 42.0 16.4

PAGE 170

159 Table 4.11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_6 (16.4 ha), Second Year (wheat) Fertilize 289 350 289 289 1 8.0 16.4 Harrowing 289 350 311 311 1 8.0 16.4 Plowing 289 350 317 318 2 16.0 16.4 Planting 320 366 326 327 2 12.0 16.4 FertiSpreading 396 425 402 403 2 16.0 16.4 Harvesting 502 528 500 500 1 12.0 16.4 Field_7 (10 ha;

PAGE 171

160 Table 4 . 11 — Continued ScSt ScFn AcSt AcFn Wrk Wrk WArea NoWrkDys Operation Julian Day Dys Hrs (ha) R M Field_8 (11.8 ha), First Year (Soybeans) Fertilize 92 136 106 106 1 6.0 11.8 10 Harrowing 92 136 117 117 1 12.0 11.8 Bedding 106 136 118 118 1 12.0 11.8 Planting 136 182 154 154 1 12.0 11.8 Cultivationl 145 197 155 155 1 12.0 11.8 Cultivation2 166 212 166 166 1 12.0 11.8 Cultivation3 183 228 192 192 1 8.0 11.8 2 Sprayingl 197 228 198 198 1 8.0 11.8 Spraying2 214 274 215 215 1 8.0 11.8 Harvesting 284 315 289 289 1 8.0 11.8 Field_9 (8 ha) , Second Year (Soybeans) Fertilize 458 502 467 467 1 12.0 8.0 Harrowing 458 502 473 473 1 12.0 8.0 Bedding 472 502 474 474 1 12.0 8.0 Planting 502 548 507 507 1 12.0 8.0 Cultivationl 502 563 508 508 1 12.0 8.0 Cultivation2 520 578 520 520 1 12.0 8.0 Cultivations 549 589 551 551 1 8.0 8.0 10 Sprayingl 563 594 565 565 1 8.0 8.0 10 Spraying2 580 640 581 581 1 8.0 8.0 Harvesting 650 681 642 642 1 8.0 8.0 Field_10 (26.4 ha), Second Year (Cotton) Fertilize 458 502 469 469 1 12.0 26.4 1 Harrowing 458 502 475 475 1 12.0 26.4 Plowing 458 507 484 485 2 24.0 26.4 Planting 472 533 500 501 2 24.0 26.4 Sprayingl 473 533 517 517 1 12.0 26.4 Cultivationl 473 538 518 519 2 24.0 26.4 Spraying2 477 548 521 521 1 12.0 26.4 Cultivation2 492 553 522 523 2 24.0 26.4 Spraying3 497 578 524 524 1 12.0 26.4 Cultivations 533 578 547 548 2 20.0 26.4 FertiSpreading 533 580 554 556 3 20.0 26.4 Spraying4 533 578 560 560 1 8.0 26.4 Spraying5 538 609 561 561 1 8.0 26.4 Spraying6 548 610 567 567 1 8.0 26.4 1 Harvesting 625 716 665 671 5 40.0 26.4 2 Mowing 655 730 672 674 3 20.0 26.4

PAGE 172

161 total hours, days and worked area (Wrk Dys, Wrk Hrs and WArea) for each operation. In addition, the number of no-work days (NoWrkDys) due to rain (R) and due to non-availability of the machinery (M) are also shown in the table. The table indicates that the simulator was able to successfully complete its task for the entire cropping season which covered the period of day 61 (March 1 of the first year) to day 730 (December 31 of the Second Year) . All the operations for different crops were successfully completed on all the fields within their agronomic work windows. They were carried out in proper sequence, as planned. However, some of the later spraying operations (Spraying4, Sprayings, Spraying6) in cotton fields were carried out one after another with no time gaps between them. This occurred because they were planned to be carried out one after another, and the machinery and labor needed to carry them out were freely available with no other operations specified between the two sprayings. However, it can be avoided, if needed, by attaching some additional attributes to the operation object-class, by breaking up one big field into small fields and/or by defining the agronomic windows for subsequent sprayings with some time gaps between them. Expert Analysis System The reports produced by the simulation and discussed above do not provide any indication about the percentage

PAGE 173

162 utilization of different machinery and laborers working on the farm, and/or the relative timeliness of different operations. This task is performed by the Expert Analysis System. It studies these reports in the context of the resource-base available on the farm. The following sections demonstrate the functioning of the three components of the Expert Analyzer and how the information generated by them can be utilized by the user to improve his farming operation. The three components are Machinery Usage, Operations Analysis and Accumulated Work reports. Machinery usage report This report identifies the least and the most utilized items of different farm objectclasses, prepares their seasonal and monthly utilization and makes recommendations to keep them or to withdraw them from the farm, based upon their utilization level and their importance to the current farming operations, as discussed in chapter III. During the initial test runs the Machinery Usage Report identified "GeneralPlanter, " "PDSprayer" and "PDSprayer2" as not being used at all for any operation and recommended their withdrawal. They were withdrawn with no effect on the scheduling of different operations. On the Davis farm, they were probably older machines kept as backup. Table 4 . 12 presents a summary of the Machinery Usage Reports of the test run after withdrawal of the implements not

PAGE 174

163 Table 4.12 Summary of reports and recommendations by Machinery Usage Report of Expert Result Analysis System for the "success run" for Davis farm knowledge. Object Utilization Recommendation and Class Item Hrs Days Reasoning Operator Jerry 2820 286 Withdraw Ray. He has Ray 142 16 a complementary unit(s) Tractor Tractor_3 1432 131 Withdraw Tractor_5. Tractor_5 120 13 It has complementary unit(s) . Implement LandPrep Bottom Plow 476 44 Sub Soiler 64 6 Plant/ Ferti

PAGE 175

164 used at all and identified during initial runs. Table 4.13 presents their monthly usage for the first year of success run of the simulation. The laborer "Ray" is the least utilized laborer on the farm. He works less than 20% of the work hours of "Jerry" (the most utilized laborer on the farm) . In addition, he (Ray) has one or more complementary operator (s) that could carry out the tasks that were assigned to him. So the recommendation was made to withdraw him from the farm work force. In actual practice on the Davis farm, he mostly performs other non-crop operations. The usage reports on usage of tractors and plant protection implements also produced similar recommendations for ••Tractor_5" and "PCultivator" based upon their utilization level in comparison to the most utilized items ("Tractor_3" for tractors and "Sprayer" for plant protection implements) of their respective object-class. The recommendations about Sub-Soiler, Grain Drill and General Grain Combine are different. Although their utilization was less than 20% of the maximum utilized item of their object-class, still the recommendations were not to withdraw them from the farm as they do not have complementary unit(s) to carry out tasks currently assigned to them. The recommendations made by Machinery Usage Report to withdraw any object-item should be implemented with a little caution because of the following reasons. However, the user

PAGE 176

165 Table 4.13 Monthly variation of most and least utilized items of different object-classes on Davis farm during first year of simulation of the "success run . " Item Jan Monthly Utilization (Hrs) Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jerry Ray Tractor_3 Tractor 5 BottomPlow SubSoiler Planter_77 Grain Drill Sprayer PCulti -vator^ Cotton Picker General Grain Combine Operators 44 336 228 144 116 16 216 224 100 6 12 36 60 ' 8 Tractors 174 312 180 68 12 36 52 Land Preparation Implements 28 198 12 Plant and Ferti Implements 90 120 12 Plant Protection Implements 42 120 60 68 Harvesting Implements 64 56 56 168 184 00 0000000 ^. Used during the second year only. 56

PAGE 177

166 can take help from other components of the Expert Analysis System (Accumulated Work and Operations Analysis reports) and advantage of his own farming experiences in making final decisions for the withdrawal as demonstrated further in this chapter. 1) The recommendation for withdrawal of an object-item is based upon one-season simulation and do not account for the changes in cropping systems and other factors over time. 2) The recommendations only state that there are one or more complementary units to substitute the object-item to be withdrawn. It does not guarantee that these complementary unit(s) would definitely be available for work when called upon to carry out the tasks currently performed by the objectitem recommended for withdrawal. 3) The item being recommended for withdrawal, though used rarely, may be an important backup resource on the farm and cannot be afforded for withdrawal. Accumulated work report This report provides the user with an aggregate and daily work reports for any combination of object-items of farm entities over a desired interval of time. To further analyze the recommendations of the Machinery Usage Report about "Ray," "Tractor_5" and "PCultivator" this report is utilized to produce their aggregate and daily work reports for the entire cropping season (January 1 of the first year to December 31

PAGE 178

167 Table 4.14 Daily utilization report of Mr. Ray, the least worked laborer on Davis Farm Day Field Crop Operation Implement Tractor 106

PAGE 179

168 Table 4.15 Daily utilization report of Tractor_5, the least utilized tractor on Davis Farm Day Field Crop Operation Implement Operator 151

PAGE 180

169 of the second year). Tables 4.14, 4.15 and 4.16 present these reports in a concise form respectively for "Ray," "Tractor_5" and "PCultivator." The aggregate work hours for different farm object-items being analyzed produced by this report (Tables 4.14-4.16) exactly matched the hours produced by the Machinery Usage report. It shows that the two reports are working correctly. In addition, the tables present some supplementary information which can be utilized to further analyze the recommendations of the Machinery Usage Report. It seems that "Ray" and "Tractor_5" have some things in common which should be considered in deciding their withdrawal from the farm. Both of them are used mainly for lighter operations such as fertilizer spreading and are used together for most of the time. For example, "Ray" operated "Tractor_5" for 10 out of 13 total working days during the cropping season. It seems "Tractor_5" makes a good match with "Ray" for lighter operations such as fertilizer spreading and spraying. The withdrawal of either of them could lead to engaging heavier tractors and/or operators, which might not be economically viable and could lead to delays in other operations. However, the Davis farm has another tractor ("Tractor_4") of similar specifications which might be able to fill in its gaps at no extra cost. To further analyze the recommendations, the user can and should also consult the Operations Analysis Report to receive

PAGE 181

170 its advice about various operations carried out by the objectitems being considered for withdrawal. Operation analysis report This report analyzes different operations for their timely start and timely completion. It identifies factors for their delays and makes recommendations to overcome them in a cost effective manner. The two versions of this report, as stated earlier, have been developed. They respectively work with a built-in (one-third rule) and user-supplied heuristics for qualifying delays in operations and subsequently finding their remedies. Table 4.17 summarizes the recommendations of the Operations Analyzer with the built-in heuristics for the operations employing "Tractor_5, •• "Ray" and/or "PCultivator. " This table shows that the operations performed employing these object-items either did not have a timeliness problem or their problems were not directly related with the object-items recommended for withdrawal. In most cases, the advice was to increase work hours or speed for the operations prior to ones engaging these object-items. To verify the functioning of the second version of the Operations Analysis Report, the operation of "Cotton" planting on "Field_3" was selected for the analysis by it. This operation has scheduled work window between Julian days 106 to 161 (corresponding to April 14 to June 8) and operation

PAGE 182

171 Table 4.17 Recommendation of Operations Analyzer for the operations carried out by "Tractor_5", "Ray" and/or "PCultivator" Field Crop Operation Prob" Recommendation Field

PAGE 183

172 completed in one day on the 125^'' Julian day (corresponding to May 3rd) . With the critical window between May 5 and May 25, the analyzer was able to identify the timely start and timely completion of the operation. However, when the critical window was changed to April 20 to May 25, the analyzer identified the delayed start and timely completion of the operation and recommended to increase the working width of the planter ("Planter_77") used for the planting operation. The scheduled work hours and speed of operation for "Planter_77" were at their upper limits and there was no possibility of increasing them. Considering the recommendations of the different components of the Expert Analysis System, additional test runs were made to study the validity of these recommendations and demonstrate the functioning of FARMSYS as a decision-aid tool. The results of each run are described briefly below. Test Runs with FARMSYS Run 0. This run was made by withdrawing "Chisel Plow," "General Planter" and "PDSprayer" from the farm using the Information Management System and with no changes in work schedule. It produced exactly the same simulation reports (Table 4.11) as the success run. However, the Machinery usage report indicated that there were two more implements namely

PAGE 184

173 "NoTillPlanter" and "PDSprayer2 , " which were not being utilized at all. Run 1 . This run was made by withdrawing "NoTillPlanter" and "PDSprayer2" in addition to "Chisel Plow," "General Planter" and "PDSprayer," and it also resulted in the same simulation report. However at this stage, the Machinery Usage Report indicated that there were no more object-items (machinery and labor) which were not being utilized at all. The earlier discussion about the recommendations of various reports of Results Analyzer was based upon this run. Run 2 . This run was made by withdrawing "Ray" from the farm with no other change in the work schedule or implement parameters. The simulation run was successfully completed with all operations being completed within their agronomic work window. However, there were slight shifts in the actual start and completion of certain operations which initially involved "Ray." Most of these were spraying operations on different fields (Table 4.18) which were delayed by a day or two. This happened because "Keith," the substituting operator, was busy elsewhere and was not available to start the operations on days carried out during earlier simulation. To study the affect of withdrawal of "Ray" on the performance of "Tractor_5," the Accumulated Work Report was used to produce its daily utilization report (Table 4.19). Although, the types of operations carried out by "Tractor_5" during the two simulations were similar, there were some

PAGE 185

173

PAGE 186

175 Table 4.18 — Continued Operation S . Window SSt SFn Case 1 ASt AFn Case 2 ASt AFn Case 3 ASt AFn Field_6 (16.4 ha), Second Year (Wheat) Fertilize 289 350 289 289 290 290 290 290 Field_7 (10.0 ha), First Year (Peanut) Cultivation2 151 197 151 151 151 151 Spraying4 183 223 186 186 186 186 Spraying5 192 243 194 194 196 196 Field_7 (10.0 ha). Second Year (Cotton) FertiSpreading 533 580 553 553 554 554 Spraying4 533 578 557 557 558 558 Spraying5 538 609 558 558 559 559 Sprayinge 548 610 559 559 560 560 Field_8 (11.8 ha), First Year (Soybeans) Fertilize 092 136 106 106 109 109 Harrowing 092 136 117 117 117 117 Bedding 106 136 118 118 118 118 Sprayingl 197 228 198 198 202 202 547 548 548 552 152 152 184 184 193 193 556 556 559 559 560 560 561 561 117 117 118 118 119 119 208 208 547 548 554

PAGE 187

176 Table 4.19 Daily utilization report of "Tractor_5", the least utilized tractor on Davis farm after withdrawal of "Ray" Day

PAGE 188

177 changes in actual operations performed by it ("Tractor_5") in the two cases. It was also interesting to note that the overall utilization of "Tractor_5" decreased from 120 hours in 13 days to 108 hours in 11 days with the withdrawal of "Ray" from the farm. And "Keith," another laborer on the farm, became its operator for all eleven days. The reduction in work hours of "Tractor_5" may mainly be attributed to the non-availability of an operator to operate "Tractor_5" all the days it became a possible choice for work. Run 3 . This run was made by withdrawing "Tractor_5" in addition to "Ray" with no other change. The simulation was successful in completing all the operations within their agronomic work windows. There were some additional shifts in the start and/or completion of spraying operations (Table 4.18). However, it was interesting to note that some operations such as "Spraying4" and "Sprayings" on "Field_6" got expedited with the combined withdrawal of "Ray" and "Tractor_5." This may primarily be attributed to the priorities of different items of different object-classes (implement, tractor and operator) used to carry out various tasks. At this stage, "Tractor_2" became the least utilized tractor on the farm (Table 4.20). However, it was not recommended to be withdrawn from the farm because it was utilized more than 20% of the most utilized tractor ("Tractor_4") . However, the recommendation for withdrawal of "PCultivator" remained unchanged.

PAGE 189

178 Table 4.20 Effect of withdrawal of the least utilized items of different farm object-classes the recommendations of Machinery Use Report Run and Specification Ob j ectItem Usage (Hrs) Recommendation 1. With Jerry "Ray" , Ray "Tractor_5", Tractor_3 "PCultiTractor_5 vator" & Sprayer "MCultiPCultivator vator" 2. Without "Ray" 3. Without "Ray" and "Tractor 5" 4 . Without "Ray" , "Tractor" , and "PCultivator" Jerry Keith Tractor_3 Tractor_5 Sprayer PCultivator Jerry Keith Tractor_4 Tractor_2 Sprayer PCultivator Jerry Keith Tractor_4 Tractor_2 Sprayer MCultivator 2820 142 1432 120 552 24 2844 734 1428 108 560 24 2924 654 1492 516 560 24 2912 654 1480 516 560 72 Withdraw "Ray" Withdraw "Tractor_5" Withdraw "PCultivator" Do not withdraw "Keith" Withdraw "Tractor_5" Withdraw "PCultivator" Do not withdraw "Keith" Do not withdraw "Tractor_2" Withdraw "PCultivator" Do not withdraw "Keith" Do not withdraw "Tractor_2" Withdraw "MCultivator" 5. Without Jerry 2896 "Ray", Keith 630 "Tractor_5", Tractor_3 1468 "PCultiTractor_2 516 vator" & Sprayer 560 "MCultiSprayCoupe 280 vator" Do not withdraw "Keith" Do not withdraw "Tractor_2" Do not withdraw "SprayCoupe"

PAGE 190

179 Run 4 . This run was made by withdrawing "PCultivator. •• All the operations were successfully completed within their agronomic work windows with some additional shifts in start and/or completions times of the different operations. However, at this time, the Machinery Usage Report identified "MCultivator" as the least utilized plant protection implement (Table 4.20) and recommended its withdrawal from because it was also utilized less than 20% of the most utilized item (Sprayer) of the same object-class. Run 5 . This run was made by additionally withdrawing "MCultivator." The simulation completed all the operations within their agronomic work windows. After this simulation the recommendations of the Machinery Usage Report were not to withdraw any of the least utilized machinery or labor (Table 4.20) because they were either unique object-items on the farm and did not have any complementary unit to substitute for them or they had a reasonably good utilization level. Some additional runs were made by removing some of the least utilized object-items (not recommended for withdrawal) to test the accuracy of recommendation. In these runs there were one or more operations not completed within the agronomic work windows which resulted in work area less than the cultivated area.

PAGE 191

180 Yield Estimation System This component of the decision system estimates the production of one or more crops grown on the farm. The knowledge-bases developed utilizing IBSNAT crop models and "Dry" weather year (1954, Tallahassee, FL) showed little variation in the peanut yields and an inverted U-shaped distribution for soybeans yields for different weeks during their respective planting windows. These yield results for this particular location and year make it difficult to demonstrate the effect of delayed operations utilizing these knowledge-bases . As cotton is the major crop of the test farm (Davis farm), a hypothetical distribution (Figure 3.16) of yield response to planting weeks within its agronomic window was assumed and a knowledge-base was developed varying the yield from 600 Kg/ha to 800 Kg/ha within the planting window utilizing this distribution. This knowledge-base has been utilized to demonstrate the functioning of the Yield Estimation System an integrated component of the decision system. Tables 4.21a and 4.21b present summary reports of this system for the runs with 12 and 10 daily work hours during April to June (the agronomic work window of cotton planting for the test farm) . As expected, the shorter work hours caused delays in planting cotton, thus reducing yields and overall farm profit from this crop. The total area under

PAGE 192

181 Table 4.21a Effect of scheduled work hours during planting period on yield, production and profits from cotton on Davis farm, a) 12 hours of daily scheduled work during planing window, b) 10 hours of scheduled daily work during planting window. Field Area (ha) Planting Yield Total Total Total Profit St. Fn. (T/ha) Prod. Sale Cost Total /ha -JdaysTon ($) ($) ($) ($) fieldl

PAGE 193

182 cotton on the test farm of 444.8 hectares produced 349.6 Tons and had net profit of $ 183/hectare with 12 hours of scheduled work. With the reduced work hours the production as well as net profit reduced because of lower yields form most of the fields. The overall production decreased to 340.1 Ton and net profit per hectare to $ 139.5 representing approximately 23% reduction in net profits. The test runs made to evaluate the recommendations of Expert Analysis System did not cause any change in the yield reports because in all these cases the shifts in timings were mainly for spraying operations to which the crop yield knowledge-bases are not currently designed to respond to. However, it is possible to modify them if appropriate information is available. Integrated Decision System The integration of the four components: Information Management, Operations Simulation, Expert Analysis and Yield Estimation Systems in a seamless manner has been successfully performed under the umbrella of FARMSYS. FARMSYS acts a controller for all four components which make use of common knowledge-bases stored in the form of dynamic databases of PROLOG. It can be utilized as decision-aid for a variety of farm systems under different climatic conditions. A team of experts who evaluated the professional qualification of FARMSYS found its components and logic

PAGE 194

183 captured in them adequate designed and widely applicable for a variety of fanning situations. Four components of FARMS YS functioned correctly, intelligently and in harmony with one another on the Davis farm knowledge used as a test farm for their operational verification. The Operations Simulation successfully simulated farm operations for complete cropping season and responded, as expected, to the variations in scheduled work hours and to the withdrawal of machinery and laborers. The Expert Analysis System has several ways to interact with the user to help him improve the productivity of his farm system. Its different components successfully imitated the behavior of machinery management expert (s) and acted according to the heuristics captured in them. The Machinery Usage report was able to identify the machinery and labor, not very important to the current farming system of the test farm. The Accumulated Work report and Operations Analysis report respectively provided the detailed analysis about the usage and the operations carried out by object-items recommended for withdrawal by the Machinery Usage report. This analysis was helpful in making final decisions about their withdrawals which were accurate and effective in reducing machinery and labor on the test farm. The decisions made after these recommendations demonstrated the possibility of reducing machinery and labor force from the farm without

PAGE 195

184 significantly affecting the timeliness of the majority of farm operations (Table 4.22). The Yield Estimation system responded successfully and accurately to the variations in scheduled work hours during April to June. The lower scheduled work hours during this period resulted in delayed planting of cotton on most fields, thus reducing the cotton yields and profits from different fields. The changes in farm knowledge-bases for all of the above tests were carried out using the Information Management System, thus proving its successful functioning as an integral component of FARMSYS, a knowledge-based decision support system for multi-crop production systems.

PAGE 196

185 Table 4.22 Comparison of machinery and labor resources on Davis farm available and recommended by FARMSYS Available List Recommended List Implements Operators Tractors (HP) DiskHarrow

PAGE 197

CHAPTER V CONCLUSIONS AND RECOMMENDATIONS The principal objective of this dissertation to represent and manipulate farm operational knowledge, including dynamic processes as well as heuristics for expert planning and management for machinery, labor and other resources was successfully accomplished utilizing knowledge engineering concepts of artificial intelligence. It has opened up a new horizon for developing decision-aid systems for complex agricultural problems. This new approach permitted seamless integration of simulation and knowledge systems, including their necessary databases. The use of PROgramming in LOGic (PROLOG) for engineering farm knowledge facilitated simulating field operations in an object-oriented manner. The inferencing capability of PROLOG were utilized to incorporate several expert systems within the simulation to make heuristic decisions and other types of searches at various stages of simulation. The object-oriented approach to simulation helps in capturing system's knowledge and depicting its dynamic behavior in a much more realistic manner than the conventional approaches to simulation. This 186

PAGE 198

187 approach also permits easy modifications and upgrades in the program code because of its modular structure. An operational scale decision-support system, FARMSYS, consisting of an intelligent information management system, an object-oriented operations simulation, an expert analysis system and a crop yield estimation system was designed and constructed. It was also evaluated for its professional qualifications and operational capabilities using a real farm knowledge set. The structure of the simulation in two distinct components: farm and regional knowledge, and simulation procedural knowledge has resulted in a versatile and flexible system which can be adjusted for a variety of farming situations ranging from highly mechanized farm (such as Davis farm) to a subsistence labor intensive farm with no mechanization at all. The encouraging results of the evaluation session for the professional qualifications of FARMSYS by a team of experts and verification of its operational capabilities through the use of a real farm knowledge set clearly indicate the possibility of using it as a decision-aid tool for planning and managing farming operations under a variety of farm situations. The concept of seamless integration of simulation and expert systems and their ability to use common knowledge-bases can be used for a variety agricultural and industrial applications.

PAGE 199

188 A few additional thoughts to further enhance the capabilities of FARMSYS as a decision-aid tool are presented below. 1) This research was mainly directed to handle the crop production component of a farm system. Most farms, especially small scale enterprises also have animal production as an integral component of their farming systems. The inclusion of an animal component in the representation of farm knowledge would result in a more practical farm model and decision-aid. 2) The scheduling of work hours for simulating field operations are currently adjusted on the global basis for the whole farm. All farm object-items are available for the entire cropping season and work the same number of hours for a given day. In real world situation, many farms have varying work hours for different members of their labor crew and even hire extra labor and machinery to meet their seasonal peaks. This can be achieved by assigning a list of work hours to each item of machinery and laborer class of the farm. This would permit adjusting scheduled work hours for each of them individually and also inclusion of custom hiring in and out of extra machinery and labor during critical periods of the cropping season. 3) The actual work hours for an operation for a day are currently based upon its type, the scheduled work hours and rainfall of the day. However in the real world situation, the past and expected future weather play a very important role

PAGE 200

189 in fanner's decision for his working hours for the day. The inclusion of this factor would make the simulation more accurate. In addition, there is a need to employ some systematic studies to develop genuine heuristics which govern the actual work hours for different regions. 4) Most farmers are interested in estimating the cost of machinery and labor component in their crop production activities. The incorporation of this factor utilizing some of the existing packages or developing a specialized one for FARMSYS would improve its (FARMSYS) acceptability for commercial enterprises. This can be done by attaching another attribute (cost/hour) for each machinery and labor on the farm. 5) All agricultural operations for crop production are sequential. They can be carried out one after another. However, certain operations such as two consecutive applications of a pesticide may require a minimum time delay between them to be effective. There is also a need to attach a factor of importance to different operations. This factor then would decide for the continuation of subsequent operations if any of the earlier operations have failed completely or partially. It would avoid the situation of not harvesting a field which has been planted, but could not cultivated.

PAGE 201

190 All these can be achieved by assigning some additional attributes to the operations object-class. 6) The effect of delayed harvesting on yield loss is not included in the crop models utilized for generating crop yield knowledge-bases for the Yield Estimation System. Therefore, there is a need to develop functions and/or expert knowledgebases on yield losses due to a late harvest of different crops under various environments. 7) FARMSYS is currently designed for strategic planning and not for tactical management in real time. In addition, it is structured to handle a farm with a certain level of mechanization either through tractor or animal traction. However, its structure permits modifying to work as a tactical management tool and/or to handle labor intensive farming with no mechanization at all. For a tactical management decision-aid tool in real time the adaptation needed would be 1) to stop the simulation at pre-defined interval and save the current environment, 2 ) present the current situation to the user, 3) provide him with the opportunity to make decisions about further actions either from his own experience or based upon the recommendations from the Expert Analysis System, 4) letting the user make changes in the resource-base and/or management strategies and 5) picking up the saved environment and continuing for simulation with the new resource-base until the next pause stage.

PAGE 202

191 The adaptation of FARMSYS for labor intensive farming for subsistence agriculture of developing countries would require 1) defining a field with a number of crops simultaneously and operations list attached directly to the field rather than the individual crop, 2) the possibility of defining a list of farm laborers (family or hired) to carry out different operations and to allocate them to the field whenever that operation is carried out and 3) a built-in mechanism to estimate the operational capacity of the crew of laborers working for an operation based upon age and sex of these individuals.

PAGE 203

APPENDIX I KNOWLEDGE-BASES Crop Yield Knowledge-bases General format cropyld(CropName, Year of Simulation, Variety, Soil Type, Irrigation, Fertilization, Planting Week, DaysToMutrity, Irrigation, Yield) It would contain numerous entries depending upon the combinations of various management inputs. Hypothetical examples for the some crops of the test farm follow. cropyld( "Soybeans", "Dry", "Kirby", "Sandy Loam", "Notirrigated", "Fertilized", 19, 136, 0, 0.8) cropyld( "Peanut", "Dry", "Florunner", "Sandy Loam", "Notirrigated", "Fertilized", 14, 128, 0, 2.05) cropyld( "Wheat", "Dry-Dry", "FL302", "Sandy Loam", "Notirrigated", "Fertilized", 47, 145, 0, 5.8) Knowledge Generated by Information Manager The following are the contents of different farm files of Davis Farm used as a test farm for different components of FARMSYS . Farm File General format farm (Name , Location , Total Area , CultArea , Activity , Code) The farm file contains only one entry as follow. farm ( "DavisFarm" , "SantaRosa" ,400,400, "CropProduction" , " dvs") 192

PAGE 204

193 Labor File General format labor (Num, Name , Sex , FunctionList , AvailStatus) It contains 4 entries one for each labor. labor ("Laborer_l"," Jerry", "m", ["General"] , "Avail") labor ("Laborer_2"," Joe", "m", ["General"] , "Avail") labor ("Laborer_3", "Ray ","m", ["General"] , "Avail") labor ("Laborer_4", "Keith", "m", ["Genral"] , "Avail") Tractor File General format tractor (Num, Model , HP , OperatorList , AvailStaus) It contains 5 entries one for each tractor. tractor("Tractor_l","JD4450",148, ["Jerry"] , "Avail") tractor("Tractor_2","JD4430",125, ["Keith", "Jerry", "Joe"], "Avail") tractor ( "Tractor_3" , " JD2950" , 90 , [ "Joe" , "Keith" ] , "Avail") tractor ("Tractor_4","JD3 02 0", 70, ["Jerry", "Joe", "Ray", "Keith"] , "Avail") tractor ("Tractor_5","JD2 640", 70, ["Jerry", "Joe", "Ray", "Keith"], "Avail") Implement File General format implement (Num, Type , Name, Tractor List , Width, Speed, AvailStatus) It contains 25 entries one for each implement, example for each type of implement follows. implement ("Implement_2" , "LandPrep" , "DiskHarrow" , [ "Tractor_l" , "Tractor_2" ] , 4 . 74 , 7 , "Avail" ) implement (" Imp lement_5", "PlantProtection", "SCultivator " , [ "Tractor_3 " , "Tractor_4 " , "Tractor_5"] , 3.6,7, "Avail") implement ( "Implement_14" , "PlantFerti" , "GeneralPLanter" , [ "Tractor_3 " ] , 3 . 6 , 8 , "Avail" ) implement ("Implement_2 2" , "Harvesting" , "PeanutCombine" , [ "Tractor_l" ] , 1 . 8 , 3 . 5 , "Avail" )

PAGE 205

194 Crop File General format crops (Num, Name , OperationsList ) The crop file contains 8 entries, 2 for each crop to account for two years, example for one year entry for each crop follow) crops ("Crop_3" , "Wheat" , ["Fertilize" , "Harrowing" "Plowing", "Planting", " Fert iSpr ead ing " "Harvesting"]) crops ("Crop_7", "Soybeans", ["Fertilize", "Harrowing" "Bedding" "Planting", "Cultivation!", "Cultivation2" "Cultivation3", "Sprayingl", "Spraying2" "Harvesting"]) crops ("Crop_2", "Cotton", ["Fertilize", "Harrowing" "Plowing", "Planting", "Sprayingl", "Cultivation!" "Spraying2", "Cultivation2" , "Sprayings" "Cultivations", "FertiSpreading", "Spray ing4" "Sprayings", "Sprayings", "Harvesting" , "Mowing" ] ) crops ("Crop_4", "Peanut", ["Fertilize", "Harrowing" "Plowing", "Planting", "Cultivation!", "Spraying!" "Cultivation2" , "Spraying2", "Spraying3" "Spraying4" , "Sprayings" , "Harvesting"] ) Field File General format fieldi(Num, Name, CultArea, SoilType, CropList, VarietyList, MaturityDaysList , FertilizationLevelList , IrrigationStatus, Operator forlrrigat ion, Costof Product ionPerHectList, SalePricePerTonList, AvailStatus) It contains 23 entries, one for each field, example of two fields follows. fieldi("Field_!", "field!", 20, "SandyLoam", ["Cotton", "Wheat"], ["DPL4!", "FL302"], [150, 165], ["Fertilized", "Fertilized"], "Notlrrigated", "NotNeeded", [750,125], [1200, !!0], "Avail") fieldi("Field_!2", "field!2", 2.4, "SandyLoam", ["Cotton", "Cotton2"], ["DPL90" , "DES119" ] , [150,150], ["Fertilized", "Fertilized"], "Notlrrigated", "NotNeeded", [750,750], [1200,1200] , "Avail")

PAGE 206

195 Operation File General format operations (Type, Name, Crop, EarlistStartTime, LatestFinishTime, WorkHrsCondList, ImpList, Eff) It contains 84 entries, one for each operation example for planting operations for different crops follows. operations ( "PlantFertiOps" , "Planting" , "Soybeans" , 136, 182, [[0,3,1], [3,8,0.5]], [ "Planter_77" ] , 0.76) operations ("PlantFertiOps", "Planting", "Wheat", 320, 366, [[0,3,1], [3,8,0.5], [ "GrainDril" ] , 0.76) operations ("PlantFertiOps", "Planting", "Cotton", 106, 161, [[0,3,1], [3,8,0.5]], ["Planter_77"] , 0.76) operations ("PlantFertiOps", "Planting", "Peanut", 106, 121, [[0,3,1], [3,8,0.5]], ["Planter_77"] , 0.76) T ype File General format type(EntityName,ItemList) It would contain variable number of entries depending upon the farm size and its activities. The contents of this file of the test farm are listed below. type("opsimplementtype", ["LandPrep", "PlantFerti", "PlantProtection" , "Harvesting" ] ) type("LandPrepOps", ["Fertilize", "Bedding", "Harrowing", "Plowing", "Mowing" , "End" , "AddNewItem" , "DeleteAnltem] ) type ("PlantFertiOps", ["End", "FertiSpreading", "Planting"]) type ( "PlantProtectionOps" , [ "Spray ing7" , "Cultivation4" ,"Sprayingl", "Spraying2", "Spraying3", "Spraying4", "Spraying5", "Spraying6", "Cultivation!", "Cultivation2", "Cultivation3", "AddNewItem", "DeleteAnltem"]) type ( "HarvestingOps" , [ "Harvesting" , "End" ] ) type("LandPrepImp", ["FertiSpreader", "Ridger", "DiskHarrow","DiscPlow", "MBPlow", "BottomPlow" , "MBPlowl" , "AddNewItem" , "DeleteAnltem" ] ) type("PlantFertiImp", [ "Planter_77" , "CottonSeeder" , "GeneralPLanter", "FertilizerSpreader", "AddNewItem" , "DeleteAnltem" ] )

PAGE 207

196 type("PlantProtectionImp", ["SCultivator", "MCultivatorl" , •'MCultivator2 " , "LBCultivator" , "PCultivator", "Sprayer", "PDSprayer", "PDSprayer2", "SprayCoupe", "AddNewItem" , "DeleteAnltem"] ) type("HarvestingImp", ["BMower", "GeneralGrainCombine" , "PeanutCombine", "CottonPicker", "AddNewItem", "DeleteAnltem"]) type ("crop", ["Cotton", "Wheat", "Cotton2", "Soybeans", "Soybeans2", "Corn", "Peanut", "AddNewItem", "DeleteAnltem"]) type ("Soybeans", ["Kirby", "Bragg", "Centennian" , "AddNewItem" , "DeleteAnltem" ] ) type ( "Peanut" , [ "Florunner" , "AddNewItem" , "DeleteAnltem" ] ) type ( "Cotton", ["S0CS4 53", "DLP90", "DES119", "SOS106", "DLP41", "AddNewItem", "DeleteAnltem"]) type ( "Wheat" , [ "FL302 " , "AddNewItem" , "DeleteAnltem" ] ) type ( " irrigation" , [ " Irrigated" , "Notirr igated" ] ) type("soiltype", [ "SandyLoam" , "SiltLoam", "ClayLoam", "FineSand"]) type ("fertilization", ["Fertilized" , "NotFertilized"] ) type ("activity", ["CropProduction", "Livestock", "MixedFarming" ] ) Knowledge Utilized by Information Manager Screen Files General format field (Name , Type , StartRow, StartCol , Length) txtf ield ( StartRow , StartCol , Length , Text) windowsize (Right, Width) The contents of the screen file for constructing screen layout for collecting General Farm information are listed below. f ield ( "action", str, 6, 35, 25) field ( "name" , str , 8 ,28,29) field ( "location" , str ,10,28,23) field ( "tarea" , real , 12 , 35 , 11) field ( "cultarea" , real ,14,35,11) field ( "activity" , str, 16,47,30) field ( " f ilesexten" , str, 18,53,4) txtfield(8,12,12,"Name of Farm") txtf ield ( 10 , 12 , 8 , "Location" ) txtf ield ( 12 , 12 , 14 , "Total Area (ha) " ) txtf ield (14,12,19, "Cultivated Area (ha) " ) txtfield(4,0,16," ") txtfield(2,0,10," »•)

PAGE 208

197 txtfield(0,ll,l, '•*••) txtfield( 1,11,1,"*") txtfield(2,ll,l,"*") txtfield(3,0,67," * k****************************************************'^ txtfield(0, 16,48, "FARMSYS-A Decision Support System for Multi-Crop") txtfield(0,66,3," *••) txtfield(l,66,3," *") txtfield(3,68,l,"*") txtfield(l,30,20," Production Systems") txtfield(2,13,56, " Farm Information Manager-General Farm Information *") txtfield(6, 12,23, "Action being Performed ") txtfield(18,12,35,"Farm generally known as (3 letters)") txtfield(16,12,31,"Press to Select Activity") windowsi2e(20,77)

PAGE 209

APPENDIX II MINI -CONFERENCE FOR FARMSYS QUALIFICATION PROGRAM Decision Support System with Logic Programming Agricultural Engineering Department University of Florida November 14, 1988 8:30 a.m. -Purpose of the meeting, and schedule adjustments Dr. Peart 8:45 a.m. -Introduction to FARMSYS and to the concepts of "Qualifying" rather than "Validating" knowledge-based systems Harbans Lai and Dr. Peart 9:30 a.m. Orange juice break 9:45 a.m. Demonstration of FARMSYS and introduction to questionnaire Harbans Lai and Dr. Peart 11:15 a.m. -Operations management research, MACH II and U.S. Sugar Dr. W. D. Shoup 11:45 a.m. Lunch 1:15 p.m. Qualification Session with FARMSYS using questionnaire Harbans Lai and Dr. Peart 2:45 p.m. Break 3:00 p.m. Review of the international DSSAT program Dr. Shrikant Jagtap 3:45 p.m. Open Session (Discussion on approaches and procedures for evaluating knowledge-based systems) 5:00 p.m. Adjourn 198

PAGE 210

199 Table II-l Participants Names and Addresses Name Address Dr. John Ogilvie Dr. Bill Chancellor^ Dr. Maurice R. Gebhardt^ Director, School of Engineering University of Guelph, Ontario, Canada Professor, Dept. of Agric. Engg. University of California, Davis, CA 95616 Professor, Agric. Engg. Bldg. USDA-ARS, University of Missouri Columbia, MO 65211 Dr. M. Zohadie Bardaie Dr. Kenneth L. Von Bargen^ Dr. Thomas S. Colvin^ Dr. Garry D. Bubenzer^ Professor, Agric. Engg. Dept. University Pertanian Malaysia 43400, Serdang, Selangor, Malaysia Professor, Agric. Engg. L. W. Chase Hall, Univesity of Nebraska Lincoln, NE 68583-0726 Agricultural Engineer, USDA/ARS 213 Davidson Hall, Iowa StateUnivesity Ames, lA -50011 Chairman, Agric. Engg. Dept. University of Wisconsin 460 Henry Hall, MadisonWI 53706 Dr. R. K. Sprinkel Assoc. Professor, Int. Pest Management Entomology and Nematology, Univ. of Florida Gainesville-FL 32611

PAGE 211

200 Table II-l — continued Name Address Dr. Peter Hildebrand Dr. Larry Bagnell Professor, FSR/E Food and Resource Economics Univ. of Florida Gainesville -Fl 32611 Professor Dept. of Agric.Engg. Univ. of Florida Gainesville -FL 32611 Dr. M. Peart Dr. J. W. Jones Grad. Research Professor Dept. of Agric.Engg. Univ. of Florida Gainesville -FL 32611 Professor Dept. of Agric. Engg. Univ. of Florida, Gainesville -FL 32611 1Participants who filled in the questionnaire on FARMSYS

PAGE 212

201 FARMSYS Evaluation and Qualification Harbans Lai and R. M. Peart Please indicate the extent to which you agree or disagree with the different statements. 1 — Strongly agree 2 — Agree 3 — Undecided 4 — Disagree 5 — Strongly disagree Evaluation of different components 1. Information Manager This component is designed to collect information about a new farm and let the user make changes in the already existing farm. The important requirements for this component are ease and user-friendliness in collecting and updating farm information and checking the integrity of the supplied information. Let us see if we have been able to incorporate these features effectively. Please evaluate screen layouts for collecting information about different farm entities. STRONGLY STRONGLY AGREE DISAGREE Screen layouts for collecting information about different farm entities is well designed. 4 5 Mechanism of letting user develop and maintain knowledge-base specific to his farm is unique for FARMSYS. 4 5 Mechanism of retrieving, presenting old information, letting user make changes and saving new information are adequately designed. 4 5 Information Manager is qualified to let user develop new farm and modify information about existing farm. 1 2 4 5

PAGE 213

202 2. OPS-SIMULATOR The Ops-Simulator is designed to simulate the field operations to predict the scheduling of different field operations. The effectiveness of Ops-Simulator in depicting the real world situation depends on its formulation and incorporation of the factors controlling these operations in as realistic a manner as possible. The key features of this component have been identification of different components of an operational knowledge of a farm, its representation and manipulation to generate new knowledge which can be then utilized by other components of FARMSYS. Please evaluate the approach to simulating field operations. 2 . 1 Knowledge-Bases STRONGLY STRONGLY AGREE DISAGREE The semantic representation of farm knowledge (to be explained) adeqpiately expresses the farm knowledge for multi-crop production system. 12 3 4 5 The components of the following knowledge-bases are adequately structured (to be explained) . a) Farm Knowledge: Farm Labor Tractor Implement Equipment Crops Fields Operations b) Regional Knowledge: Expert File Weather File c) Output Reports: Work Reports 12 3 4 5 No-Work Reports 12 3 4 5 Summary Report 12 3 4 5 Please evaluate the following features of the Ops-Simulator for farm operations simulation modelling. Do they allow us to develop a simulator which would predict the system's behavior in a more accurate and realistic manner than most conventional simulators. Indicate to what extent you agree or disagree with the following statements. 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5 12 3 4 5

PAGE 214

203 2.2 Simulation Methodology STRONGLY STRONGLY AGREE DISAGREE The semantic representation of the farm knowledge has facilitated keeping farm knowledge separate from code of the simulation. It has resulted in a versatile and scale neutral simulator which can be utilized for different types of farm settings. The assigning of more than one operator to a tractor and more than one tractor to an implement is more realistic for farm operations modelling than generally captured in conventional simulators. 1 The checking of conditions for the field operations is carried out more rigorously than most conventional simulator using procedural languages. It has more realistic criteria for deciding actual work hours for the day's work. It uses more robust and realistic mechanism for finding the available machinery set (Implement, Tractor and Operator) than conventional simulators. The facility of adjusting the scheduled work hours for the farm prior to start of simulation is important. 1 The economics of operations is not considered in enough detail. Scheduled work hours are decided for whole farm rather than for individual operator (s) or tractor (s) .

PAGE 215

204 The expected future weather while deciding actual work hours is not considered. STRONGLY STRONGLY AGREE DISAGREE 12 3 4 5 The Ops-Simulator is qualified to simulate field operations for multi-crop production systems. 12 3 4 5 Please help identify additional weaknesses and strengths of the Simulator in comparison to other similar programs familiar to you. (Use back side of page if needed.) a) Weaknesses 1) 2) b) Strengths 1) 2) 3. YLD-ESTIMATOR The yld-estimator is designed to estimate the overall production and net profit from different crops grown on the farm. The power of this component depends upon the power of the mechanism utilized to predict yields of different crops grown on the farm under different management inputs. We utilized the IBSNAT crop models for making these estimations. However, we are interested in identifying other ways to predict crop yields. Please help us to do that.

PAGE 216

205 STRONGLY STRONGLY AGREE DISAGREE It is good to have yld-estimator as a component of the FARMSYS. However, its acceptance as a machinery management tool would not be affected significantly without it. 1 The use of crop simulation models for predicting crop yields for the farm level is not a good idea because they are not designed for this purpose. 1 The following features of the yldestimator are adequately structured: Screen layout for letting user select field (s) /crop (s) Structure and contents of the final report The yld-estimator is qualified to make yield and net return predictions if appropriate crop model (s) are used. 4. EXPERT ADVISOR The EXPERT ADVISOR is designed to analyze the reports produced by the Ops-Simulator in context of the farm resource-base (availability of the labor and machinery) and other management decisions (Scheduled Work Hours and Allotment of machinery and power sources to different operations) and make recommendations to the user on efficient and cost effective machinery management options. There are endless possible ways of analyzing the simulation results. We have taken one approach (to be explained) which may not be the best one. Secondly, the criteria utilized in analyzing machinery usage and delays in operations is further based upon some assumptions which are our intelligent guesses. Please judge the importance of these reports and evaluate the criteria utilized in their preparation. In addition, please identify the nature and format of some additional reports which would increase the power of expert advisor.

PAGE 217

206 4 . 1 Individual Reports Evaluation a) Machinery Usage Report Objective To identify the least utilized object-item of the selected machinery type or laborers and develop a recommendation about whether or not to keep it. This report is designed to identify the excess machinery available on the farm. Please give your opinion. STRONGLY STRONGLY AGREE DISAGREE The objective of the report is sufficiently strong and impressive and users will make intensive use of this report. 12 3 4 5 The criteria (to be explained) utilized for identifying the least utilized objectitem are adequate and realistic. 1 2 The criteria (to be explained) utilized for deciding recommendation about least utilized object-item are adequate and realistic. 1 2 List other criteria which could be employed for developing recommendations for the least utilized object-item. a) b) c) b) Operations Analysis Report Objective 1) Identification of Problems To identify operations which had delays in their start and/or finish, along with the factors responsible for these delays. This report is designed to identify bottleneck in timely completion of the different operations such as insufficient scheduled work hours, low working speed, or smaller size machinery on the farm.

PAGE 218

207 STRONGLY STRONGLY AGREE DISAGREE The objective of the report is sufficiently strong and impressive and users will make intensive use of this report. 12 3 4 5 The criteria (to be explained) utilized for identifying problematic operations is not adequate and needs improvement. 12 3 4 5 The break-up of the timing window is ok. 12 3 4 5 List other criteria which could be utilized for the purpose (including criteria for dividing timing window) . a) b) c) 2) Developing Recommendations The report also develops cost effective recommendations to minimize these delays. The criteria (to be explained) utilized to make the following recommendations are adequate and realistic. STRONGLY STRONGLY AGREE DISAGREE Increase Scheduled Work hours 12 3 4 5 Increase Speed of operation 12 3 4 5 Increase Working width 12 3 4 5 Suggest methods for improving the above recommendations. 1) 2) 3)

PAGE 219

208 c) Accumulated Work Report Objective To present an accumulated work report for any combination of object-items of farm entities over any desired interval of time period. This report is designed to let users know about the intensity of usage of different object-items of various farm entities. Using this report one can determine how many hours Tractor_l worked on Soybean Fields during the period January 1 to Jun 15 etc. STRONGLY STRONGLY AGREE DISAGREE The objective of the report is sufficiently strong and impressive and users will make intensive use of this report. The interactive mode for letting users select different farm object-items and time interval is adequately designed. The results of this report are presented in the form of two sub-reports namely Summary Reports and Detailed Report (to be explained) . Please evaluate these reports. Both reports are essential 12 3 4 5 Both reports are logically presented. 12 3 4 5 List other types of information which could be included to make these reports more useful. a) b) c)

PAGE 220

209 4.2 Overall Evaluation The Expert Advisor presently prepares the three reports evaluated individually earlier. However, we would like to have your overall impression about these reports. STRONGLY STRONGLY AGREE DISAGREE The Expert Advisor is an important component of FARMSYS. 12 3 4 5 The Expert Advisor is qualified to carry out its desired functions. Please list additional reports and their objectives which you would like to see included in Expert Advisor. a) Title: Objective: b) Title: Objective: 5. FARMSYS Finally, we would like to have your overall impression of FARMSYS as an integrated decision-aid tool. FARMSYS is qualified as a decision-aid tool for machinery management for multi-crop production system. 12 3 4 5 Things You Would Like To See Added To FARMSYS ITEM: Things You Would Like To See Deleted From FARMSYS ITEM: Name: Address :

PAGE 221

210 Non-Structured Responses about FARMSYS Weaknesses 1) Economic factors need to be incorporated more 2) Soil consideration on farming not adequately considered 3) Some obvious refinements not presented or communicated 4) Does not allow for information input from out side or even from internal previous day simulations in deciding what will be done on the following day. 5) Lack of use of established algorithms 6) Inability to adapt to tactical planning Strengths 1) Comprehensive in selection process 2) Concept of no-work report is very good 3) structured approach 4) Excellent framework. Most suggestions made would be good and desirable but not essential. 5) global approach 6) Tries to include a broad range of factors and data. 7) Ease of setting up 8) Flexibility of reports 9) Adaptability to diverse areas of the world. 10) The mechanism of user information input Suggestion 1) User definition of agronomic work window and critical timing of operations. 2) Include cash flow report, to keep track of cash requirement over time. 3) Looking at impact of soil beyond soil type. 4) Distinction between management and planning tool. They need different types of inputs. 5) Flexibility to account for individual criteria about machinery usage report and operations analysis report. 6) Need to accommodate more tools 7) Amount of resources needed by week or by month (fuel, labor etc.) 8) More rigorous role on soil/water/machinery management interactions. 9) multi-operations in field at same time or sub-divide the fields to allow this. 10) Utilize weather data to set initial time for operation to begin. 11) Include operation economics, cash flow projection and specific effect of operations upon profit. 12) Age of the implement for deciding recommendations about the machinery usage report, which gives idea of need for keeping back up. Other factors suggested for this report are a) potential decrease in market of machine value with

PAGE 222

211 time, b) need for the machine as back up. 13) In critical periods day could be broken down to 2 hours interval or the next job could start immediately even though it is not the start of a new day. 14) Make facility to put more than one tool in same field for the same operation or subsequent operations. 15) Add economic data for each object-item e.g. US$/hr for each worker and for each tractor and implement. 16) Graphics like Gnat chart to show actual happening vs. planned. 17) Realignability of windows based upon events which have developed on day to day basis. 18) The window should always be elongated ( even as nonpreformed choice) in order to get the land plantedno matter what. 19) A system that allows the daily choices to be made based upon the state of the fields, equipment, crop, operators and weather on the previous day. 20) Considering down time of first choice tractor, implement, etc. 21) Prepare maintenance report for tractors and implements. 22) Allow part time labor and machinery Concerns 1) The user setting all the windows for work 2) I am not sure of validity of this evaluation. Time too much of limitation. 3) What about yesterday's work conditions influencing today's work. 4) I am troubled by lack of use of the established algorithm which have been field validated. 5) I really like its data input system and its concept of priority. I think its use of algorithm for appropriate tasks such as work days available need to be evaluated.

PAGE 223

REFERENCES Addis, T. R. 1985. Designing knowledge-based systems: Knowledge for the new generation computers. PrenticeHall, Englewood Cliffs, NJ. Adelsberger, H. H. 1984. PROLOG as a simulation language. In Proc. of the 1984 Winter Simulation Conf. ed. S. Sheppard, V. Pooch and D. Pegden. SCS, San Diego, CA. pp. 501-504. AAAI and ASAE. 1988. Integration of expert systems with conventional problem solving techniques in agriculture. Proc. of the Workshop, AAAI and ASAE. Aug. 10-12, San Antonio, TX. Barrett, J. R. , J. B. Morrison and L. F. Huggins. 1985. Artificial intelligence and expert systems in agricultural research and education. ASAE paper 85-5516. ASAE, St. Joseph, MI. Batchelor, W. D. , R. W. McClendon, J. W. Jones and D. B. Adams. 1987. An expert simulation system for soybean insect pest management. ASAE Paper 87-4501. ASAE, St. Joseph, MI. Beck, H. W. and J. W. Jones. 1988. Simulation and artificial intelligence concepts. Paper presented at the Expert Systems Workshop, Orlando, FL, Feb. 1988. ASAE, St. Joseph, MI. Bender, D. 1984. Hierarchical integration of simulation and linear programming to assess risk-efficient cropping systems. PhD Thesis. Purdue University, West Lafayette, IN. Bennett, T. B. , R. S. Sowell and R. E. Sneed. 1988. An expert system for irrigation planning and design. ASAE Paper 88-5021. ASAE, St. Joseph, MI. Boggess, W. G. , and C. B. Amerling. 1983. A bioeconomics simulation analysis for irrigation investments. S. Journal Agric. Econ. 16: 85-91. 212

PAGE 224

213 Boote, B. J. and Jones, J. W. 1986. Application of and limitations in crop growth simulation models to fit crops and cropping systems to semi-arid environment. Depts. of Agronomy and Agric. Engg. University of Florida, Gainesville, FL. Borland. 1986. Turbo PROLOG: The natural language for artificial intelligence. Borland International Inc. , Scotts Valley, CA. Borland. 1987. Turbo PROLOG Tool Box: User's guide and reference manual. Borland International Inc., Scotts Valley, CA. Brown, T. L. 1974. Farm machinery selection by use of a zero-one mixed integer linear programming. MS Thesis. Purdue University, West Lafayette, IN. Bulkeley, W. M. 1986. Expert systems are entering into main stream of computers. Technology. The Wall Street Journal, Dec. 5. 1986. Burrows, W. C. and J. C. Siemens. 1974. Determination of optimum machinery for Corn-Soybean farms. Trans, of the ASAE 17(6) :1130-1135. Candler, W. 1968. A linear program for selecting a corn production system. Conf. Proceedings: Computers and Farm Machinery Management, Dec. 1968. ASAE St. Joseph, MI. pp. 20-21. Chen, L. H. 1986. Microcomputer model for budgeting and scheduling crop production. Trans. of the ASAE 29(4) :908-911. Chen, L. H. 1987. A microcomputer model for selection of machines and tractors. ASAE Paper 87-1050. ASAE, St. Joseph, MI. Chen, L. H. and R. W. McClendon. 1985. Soybean and wheat double cropping simulation model. Trans, of the ASAE 28(1) :65-69. Citrenbaum, R. , J. R. Geissman and R. Schultz. 1987. Selecting a shell. AI EXPERT. 2(9): 30-39. Coulson, R. N., L. J. Folse and D. K. Loh. 1987. Artificial intelligence and natural resource management. Science 237:262-267.

PAGE 225

214 Davis, J. R. and P. M. Nanninga. 1985. GEOMYCIN: Towards a geographic expert system for resource management. Journal of Environment Management 85(21) :377-390. Digitalk. 1986. Smalltalk/V: Tutorial and program handbook. Digitalk Inc., Los Angeles, CA. Donahue, D. W. , R. S. Sowell and N. T. Powell. 1988. An expert system for diagnosing diseases of tobacco. ASAE Paper 88-5022. ASAE, St. Joseph, MI. Edwards W. and Michael B. 1980. Machinery selection considering timeliness losses. Trans, of the ASAE-1980. pp 810-815,820. Eisgruber, L. M. 1968. Where do we go from here ? Panel discussion. Conf. Proceedings: Computers and Farm Machinery Management, Dec, 1968. ASAE St. Joseph, MI. pp 52. Elderen E. van. 1981. Scheduling of field operations: Research report. Inst, of Agric. Engg. IMAG, Wageningen, Netherland 81(3) :865-871. Elderen, E. van. 1987. Scheduling farm operations: A simulation model, Pudoc Wageningen, Netherland. Elmaghraby, A. S. and V. Jagannathan. 1986. An expert system for simulationists. In: AI Graphic and Simulation, ed. Graham Birtwistle. Soc. for Comp. Simu. San Diego, CA. pp 106-109. Engel, B. A., D. D. Jones and J. R. Wright. 1988. Selection of an expert system development tool. ASAE Paper 885017. ASAE, St. Joseph, MI. Engel, B. A., D. B. Beasley and J. R. Barrett. 1988a. Knowledge engineering in soil erosion. ASAE Paper 882140. ASAE, St. Joseph, MI. Fan, I. S. and P. J. Sackett. 1988. A PROLOG simulator for interactive flexible manufacturing systems control. Simulation 50(6) :239-247. Feigenbaum, E. A. and P. McCorduck. 1983. The fifth generation: artificial intelligence and Japan's computer challenge to the world. Addison-Wesley, Reading, MA. Fisher, E. L. 1986. An Al-based methodology for factory design. AI Magazine, Fall 1986. pp. 72-85.

PAGE 226

215 Flowers, E. B. 1988. Failing with grace. Turbo Technix. The Borland Language Journal l(5):76-85. Futo, I. and T. Gergely. 1986. TS-PROLOG a logic simulation language, TRANS, of the SCS, 3(4): 112-119. Futo, I. and T. Gergely. 1987. Logic programming in simulation, Trans, of the Soc. for the Comp. Simu. 3(3) :195-216. Gaines B. R and M. L. G. Shaw. 1986. Expert systems and simulation. In: AI Graphic and Simulation. ed. Grahm Birtwistle. Soc. of Comp. Simu. San Diego, CA. pp. 95101. Gauthier, L. and R. Kok. 1988. A microcomputer-based farm management/ operating system. Can. Agric. Eng. 30(1) :6976. Geyer, F. P., R. M. Peart and W. H. M. Morris. 1963. Bottlenecks in handling corn at harvest. ASAE Paper 63829. ASAE St. Joseph MI. Gibson, H. G. , D. D. Jones, J. R. Barrett and C. H. Shih. 1986. Timber harvesting equipment selection: An expert system. ASAE Paper 86-1604. ASAE, St. Joseph, MI. Glunz, D. J. 1985. Comparative analysis of Florida citrus harvest systems. MS Thesis. University of Florida, Gainesville, FL. Gui X. and J. C. Siemens. 1986. An optimum machinery selection model for corn soybean farm. ASAE Paper 861523. ASAE, St. Joseph, MI. Halterman, S. T. , J. R. Barrett and M. L. Swearingin. 1986. Expert systems development stages: Double cropping as an example. ASAE Paper 86-4516. ASAE St. Joseph, MI. Hart, R. D. 1984. Hierarchical agricultural systems. In: Prosepectives on farming systems research and extension, ed. Peter E. Hildebrand. Lynne Rienner Publishers, Boulder, CO. pp. 29-32. Hayes-Roth, F. , D. A. Waterman and D. B. Lenatm. 1983. Building expert system. Addison-Wesley Publishing Co. Inc. , Reading, MA.

PAGE 227

216 Helms, G. L. , J. W. Richardson, M. E. Rister, N. D. Stone, D. K. Loh. 1987. COTFLEX: A farm-level expert system to aid farmers in making farm policy decisions. Paper presented at the 1987 Annual Meeting of Am. Agric. Econ. Assoc. East Lansing, MI. Hetz, E. J. and M. L. Esmay. undated. A field machinery selection model for wheat producers in the Andes PreCordillera of south central Chile. Agric. Engg. Dept. Michigan State University, East Lasting, MI. Hoogenboom, G. , Jones, J. W. and J.W. White. 1987. Use of models in studies of drought tolerance. Paper presented at the Workshop on Drought in Dry Beans. October 1987. Centre Internacional da Agricultura Tropical, Cali, Colombia. IBSNAT. 1986. Decision support system for agrotechnology transfer (DSSAT) : Documentation for IBSNAT crop models input and output files. Version 1.0. Technical Report 5. International Benchmark Sites Network for Agrotechnology Transfer, University of Hawaii, Honolulu, HI. InelliCorp. 1988. How to get started in AI: IntelliCorp's guide to getting off on the right foot. IntelliCorp Inc., Mountain View, CA. Jones, D. D. and L. A. Hoelscher. 1987. Applications of expert systems in extension engineering. ASAE Paper 875021. ASAE, St. Joseph, MI. Jones, J. W. , K. J. Boote, S. S. Jagtap, G. Hoogenboon, and G. G. Wilkerson. 1988. SOYGRO 5.4: Soybean crop growth simulation model-user's guide. Florida Agri. Expt. Sta. Journal No. 8304. Inst, of Food and Agric. Sci.. University of Florida, Gainesville, FL. Jones, J. W. , Pierce Jones, P. A. Everett. 1987. Combining expert systems and agricultural models: A case study. Trans, of the ASAE 30(5) :1308-1314. Jones, P., J. W. Jones, P. A. Everett and H. Beck. 1986a. Knowledge acquisition: A case history of an insect control expert system, ASAE Paper 86-5041. ASAE St. Joseph, MI. Jones, P., J. W. Jones, P. A. Everett, F. A. Johnson and R. K. Sprinkle. 1986b. Development of an expert system for making insects control decisions in soybeans. Int. Conf. on Computers in Agric. Ext. Prog. Feb 1986. Orlando, FL.

PAGE 228

217 Jones, P. and J. Haldeman. 1986. Management of a crop research facility with a microcomputer-based expert system. Trans, of the ASAE 29 (1) :235-242 . Kalkar, S. and P. R. Goodrich. 1986. An expert system for animal waste management. ASAE Paper 86-4540. ASAE, St. Joseph, MI. Khuri, R. S., W. D. Shoup, R. M. Peart and R. L. Kilmer. 1988. Expert system for interpreting citrus harvest simulation. Applied Engineering in Agriculture. 4(3) :275-280. Kline, D. E., D. A. Bender, C. E. Van Donge, B. A. McCarl and J.K. Schueller. 1986. Machinery selection using farmlevel intelligent decision support systems. ASAE Paper 86-4519. ASAE, St. Joseph, MI. Kline, D. E., D. A. Bender, B. A. McCarl. 1987. Farm-level machinery management using intelligent decision support systems. ASAE Paper 87-1047. ASAE St. Joseph, MI. Konaka Toshio. 1987. Farm machinery utilization planning. AMA 18(3) :75-81. Kornecki, A. 1988. Simulation and artificial intelligence as tools in aviation education. In: AI Papers, ed. R. J. Uttamsingh. Soc. for Comp. Simu. , San Diego, CA. Simulation Series 20(1) : 121-126. Labiadh S. and J. C. Frisby. 1987. A simulation model to select alfalfa harvesting machines. ASAE Paper 87-1047. ASAE, St. Joseph, MI. Lai H. and L. C. Freire. 1984. Operational cost of animal-drawn agricultural implements in various sizes of farm holdings. Research Bulletin 21. CPATSA/EMBRAPA, Petrolina, Brazil. Lai, H., R. M. Peart and J. W. Jones. 1987. Expert systems for technology transfer. ASAE paper 87-5028. ASAE, St. Joseph, MI. Lemmon, H. 1986. Comax: An expert system for cotton crop management. Science 233:29-33.

PAGE 229

218 Link, D. A. 1967. Activity network techniques applied to farm machinery selection problem. Trans, of the ASAE 10(3) :310-316. Link, D. A. and C. W. Bockhop. 1964. Mathematical approach to farm machine scheduling. Trans, of the ASAE 7(1) :816. Loewer, O. J., M. F. Kocher and T. C. Bridges. 1988. An expert system for determining bottlenecks in on-farm grain processing systems. ASAE Paper 88-6073. ASAE, St. Joseph, MI. McKinion, J. M. and H. E. Lemmon. 1985a. Expert systems for agriculture. Computers and Electronics in Agriculture 1(1985) :31-40. McKinion, J. M. and H. E. Lemmon. 1985b. Symbolic computers and AI tools for a cotton expert system. ASAE Paper 855520. ASAE, St. Joseph, MI. Meyer, G. E. and R. B. Curry. 1986. Soybean production decision-making with the REALSOY Model. ASAE Paper 864507. ASAE, St. Joseph, MI. Miles, G. E. and Y. J. Tsai. 1987. Combine systems engineering by simulation. Trans. of the ASAE 30(5) :1277-1281. Moralee, D. S. 1986. The use of knowledge engineering in an industrial research environment A retrospect. Expert Systems and Knowledge Engineering, Elsevier Science Publishers, Holland, pp. 101-109. Morrison, J. B. 1985. Forthcoming role of artificial intelligence in agricultural science and education system. Executive Summary, Agricultural Communication Service. Purdue University, West Lafayette, IN. Moser, J. G. 1986. Integration of artificial intelligence and simulation in comprehensive decision-support system. Simulation 47(6) :223-229. Nagarajan K. , D. Singh and J. K. Wang. 1985. Optimum allocation of farm power resources in multi-crop farming systems. ASAE Paper 85-5056. ASAE, St. Joseph, MI. Nagarajan, K. , J. W. Mishoe and W. L. Currey. 1987. Development of an expert system for weed management in Soybean. ASAE Paper 87-9659. ASAE St. Joseph, MI.

PAGE 230

219 Neggahban, B. , R. C. Fluck and W. D. Shoup. 1988. Selection of lawn and garden tractors using an expert system. Applied Engineering in Agriculture 4 (3) :211-216. Nelson, T. and W. Bowers. 1968. What programs are operational now ? Conf. Proceedings: Computers and Farm Machinery Management, Dec. 1968. ASAE St. Joseph, MI. pp. 6-8. Newell, A. and H. A. Simon. 1963. GPS; A program that simulates human thoughts. In: Computers and thoughts, ed. E.A. Feigenbaum and J. Feldman. McGraw-Hill, New York, pp. 279-293. Nguyen, T A. , W. A. Perkins, T. J. Laffey and Deanne Pecora. 1987. Knowledge-base verification. AI Magazine, Summer 1987. pp 69-75. O'Keefe, R. 1986. Simulation and expert systems; A taxonomy and some examples. Simulation 46(1):10-16. O'Keefe, R. M. and J. W. Roach. 1987. Artificial intelligence approaches to simulation. J. Opl Res. Soc. 38 (8) :713-722 . Oren, T. I. 1986. Knowledge-bases for advanced simulation environment. Proc. Conf. on Intelligent Simulation Environments. Soc. for Comp. Simu. , San Diego, CA. pp. 16-22. Oren, T. I. and B. P. Zeigler. 1979. Concepts of advanced simulation methodologies, Simulation 32(3):69-82. Ozkan, H. E. and W. M. Edwards. 1986a. A farmer oriented machinery comparison model. Trans. of the ASAE 29(3) '.612-611 . Ozkan E. and W. Edwards. 1986b. Microcomputer software for machinery management. Proc. of the Int. Conf. on Computers in Agric. Ext. Prog., Orlando, FL. pp. 701-706. Ozkan, H. E., W. M. Edwards & A. Saulman. 1984. A machinery selection model for farmer decision-making. ASAE Paper 84-1521. ASAE, St. Joseph, MI. Paperback Software. 1985. VP-Planner: Spreadsheet flexibility with database power. Paperback Software International, Berkeley, CA. Pascoe, G. A. 1986. Elements of object-oriented programming. Byte 11(9) : 139-144.

PAGE 231

220 Peart R. M. and J. R. Barrett. 1979. The role simulation. In: Modification of aerial environment of plants, ed. B. J. Bar field and J.F. Gerber. ASAE Monograph (2). ASAE St. Joseph, MI. Peart, R. M. , J. R. Barrett and R. D. Smith. 1985. A cropping decision support system using artificial intelligence concepts. Agril. Engg. Dept. Purdue University, West Lafayette, IN. Peart, R. M. , H. Lai and J. W. Jones. 1988. Developing integrated decision support systems using PROLOG. Presented at the AAAI workshop on AI in Agriculture, Aug., 1988. San Antonio, TX. Pepper, J. 1986. Knowledge craft: An environment for rapid prototyping for expert systems. Paper presented at the AI for Automotive Industry Conference. March 1986. Detroit, MI. Phillips, J. J. and S. B. Harsh. 1987. An expert system application to the financial analysis of lender case farm records. Paper presented at the Annual Meeting of Am. Agric. Econ. Assoc. Lansing, MI. Plant, R. E. and T. L. Wilson. 1986. A computer based pest management aid for San Joaquin Valley cotton. Proc. of the Beltwide Cotton Conf., Nation Cotton Council of Amer. , Memphis, TN. pp. 22-24. Plant, R. E., L. T. Wilson, L. Zelinski, P. B. Goodell and T. A. Kerby. 1987. CALEX/COTTON: An expert system based management aid for California cotton growers. University of California, Davis, CA. Prerau, D. S. 1987. Knowledge acquisition in the development of a large expert system. AI Magazine, Summer 1987. pp 43-51. Pritsker, A. A. B. 1984. Introduction to simulation and SLAM II. Second Edition. John Wiley and Sons, New York, NY. Pritskar, A. A. B. and C. D. Pegden. 1979. Introduction to simulation and SLAM. Systems Publishing Corp. West Lafayette, IN. Reddy Y. V., M. S. Fox, N. Hussain and M. McRoberts. 1986. The knowledge-based simulation system. IEEE SOFTWARE, March 1986. pp 26-37.

PAGE 232

221 Rettinger, J. C. , G. E. Miles and G. E. Wilcox. 1987. Muskmelon production expert system. ASAE Paper 87-5029. ASAE, St. Joseph, MI. Rich, E. 1983. Artificial intelligence, McGraw-Hill Book Company, New York, NY. Rimmington, G. M. , R. Berger, D. J. Connor and T. A. McMohon. 1987. Expert systems and crop simulation modelling. Proc. of the Simulation Society Conf . , Melbourne, Australia, pp. 343-358. Roach, J. W. and R. S. Virkar. 1986. POMME: A computer based consultation system for apple orchard management using PROLOG. A technical report. Department of Computer Science and Applications, Virginia Polytechnic Institute and State University, Blacksburg, VA. Ruckman J. 1986. A model for computer integrated farming system. ASAE Paper 86-1519. ASAE, St. Joseph, MI. Rumsey, J. W. , L. Gautz and W. J. Chancellor. 1986. Increasing farm machinery cost effectiveness in California. ASAE Paper 86-1520. ASAE, St Joseph, MI. Shannon, R. E. 1984. Artificial intelligence and simulation, Keynote Address. In. Proc. of Winter Simu. Conf. ed. S. Sheppard, U. Pooch, D. Pegden. Soc. for Comp. Simu., San Diego, CA. pp. 4-9. Shaw, L. G. and B. R. Gaines. 1987. A framework for knowledge-based systems unifying expert systems and simulation. In Intelligent simulation environment, ed. Paul Luker and H. Adelsberger. Soc. for Comp. Simu., San Diego, Simulation series, 17(1): 38-43. Shintani T. , Y. Katayama, K. Hiraishi and M. Toda. 1986. KORE-A hybrid knowledge programming environment for decision support based on a logic programming language. In: Lecture Notes in Computer Science, ed. G. Goos and J. Hartmanis, Logic Programming' 86, Proc. of the 5th Conf., Tokyo, Japan, pp. 22-32. Siemens, J. C, K. Hamburg and A. T. Tyrrell. 1988. Farm machinery selection program. ASAE Paper 88-1056. ASAE, St Joseph, MI. Slocombe, J. W. 1986. Agricultural mechanization curricula in 2000. ASAE Paper 86-5515. ASAE, St. Joseph, MI.

PAGE 233

222 Smith, R. D. 1985. Biomass storage, decision support systems and expert systems in crop production and processing. PhD thesis. Perdue University, West Lafayette, IN. Smith, R. D. , J. R. Barrett and R. M. Peart. 1985. Crop production management with expert systems. ASAE Paper 85-5521. ASAE St. Joseph, MI. Smith, O. R. , L. D. Gaultney, J. R. Barrett, D. D. Jones and C. H. Castore. 1988. Acceptability of expert systems by agricultural computer users. ASAE Paper 88-5023. ASAE St. Joseph, MI. Smith, R. D. , R. M. Peart and J. R. Barrett. 1985. Agricultural production management with decision support systems. ASAE Paper 85-3076. ASAE, St. Joseph, MI. Sowell, R. S., T. B. Bannett, D. W. Donahue and D. M. Crohn. 1888. Total farm machinery cost analysis with dBASE III and CLIPPER. ASAE Paper 88-1055. ASAE, St Joseph, MI. Stefik M. and D. G. Bobrow. 1986. Object-oriented programming: Themes and variations, AI Magazine, Winter 1986. pp. 40-59. Stone, N. D. , R. E. Frisbie, J. W. Richardson and R. N. Coulson. 1986. Integrated expert system applications for agriculture. Proc. of Int. Conf. on Computers in Agric. Ext. Prog., Feb. 1986. Orlando, FL. pp. 836-841 Thai, C. N. and C. P. Wilson. 1988. Simulation of peach post harvest operations. ASAE Paper 88-6058. ASAE, St. Joseph, MI. Thieme, R. H. , D. D. Jones and H. G. Gibson. 1986. A knowledge-based approach to forest road planning. ASAE Paper 86-1606. ASAE, St. Joseph, MI. Thieme, R. H. , J. W. Uhring, A. Dale Whittaker, R. M. Peart and J. R. Barrett. 1985. Grain marketing analysis with an expert system. ASAE Paper 85-5519. ASAE, St. Joseph, MI. Thomson, J. S. and R. M. Peart. 1986. An expert system for soil moisture-based scheduling of center pivot irrigation. ASAE Paper 86-4518. ASAE, St. Joseph, MI. Tsai, Y. J., J. W. Jones and J. W. Mishoe. 1987. Optimizing multiple cropping systems: A systems approach. Trans, of the ASAE 30(6) :1554-1561.

PAGE 234

223 Umphress, D. A. and U. W. Pooch. 1987. A goal oriented approach to simulation. In: Methodology and validation, ed. Osman Balsci. Soc. for Comp. Simu. , San Diego, CA. Simulation Series 19(l):44-49. Von Bargen K. and J. Hines. 1973. Economic Analysis of a complement of farm machines. ASAE paper 73-1529. ASAE, St. Joseph, MI. Von Bargen K. and R. M. Peart. 1969. Simulation of field machine and transport activities for a row crop planting system. ASAE Paper 69-657. ASAE, St. Joseph, MI. Walker A., M. McCord, J. F. Sowa and W. G. Wilson. 1987. Knowledge systems and prolog; Chapter 1; Knowledge systems: Principles and practices, Addision-Wesley Publishing Co. Inc., Reading, Massachusetts. pp. 1-22. Walton, T. F. 1967. Communications and data management. A Wiley-Interscience Publication. John Willey & Sons, New York, NY. Waterman, D. A. 1986. A guide to expert systems. AddisonWesley Publishing Co. Inc., Reading, MA. Waund, D. and L. Mundell. 1968. Linear programming model for a vegetable processor. Conf . Proceedings: Computers and Farm Machinery Management, Dec, 1968. ASAE, St. Joseph, MI. Webster, N. 1979. Webster's new twentieth century dictionary of the English language. Second edition. Simon and Schuster, New York, NY. Whittaker, D. A., E. J. Monke and F. R. Foster. 1987. ADAM: An ADaptive Assembler of Models. ASAE paper 87-5536. ASAE St. Joseph, MI. Wildberger A. M. 1988a. Selection of tools for including expert system components in simulations. Paper presented at the 1988 Summer Comp. Simu. Conf., July 1988. Seattle, WA. Wildberger A. M. 1988b. Integrating an expert systems component into a simulation. In. AI Papers, ed. Ranjeet J. Uttamsingh. Soc. for Comp. Simu., San Diego, CA. Simulation Series. 20 (1) : 132-135. Williamson, M. 1985. Artificial intelligence for microcomputers: The guide for business decision makers. Brady Communication Co. Inc., A Simon and Schuster Publishing Co. , New York, NY.

PAGE 235

224 Yokoi S. 1986. A PROLOG based object-oriented language and its compiler. In: Lecture Notes in Computer Science, ed. G. Goos and J. Hartmanis, Logic Programming' 86. Proc. of the 5th Conf. Tokyo, Japan. Yost, R. 1985. Expert system to develop and transfer soil management research. Annual Report and Work Plan. TROPSOIL. Management Entity, Raligh, NC.

PAGE 236

BIOGRAPHICAL SKETCH HARBANS LAL was born on Jan. 6, 1949, in Kashipur (UP) a small town in the Tarai region of northern India. He had his secondary education in New Delhi and attended Indian Institute of Technology (IIT) , Kharagpur, WB for his Bachelor and Master degrees in agricultural engineering from 1966 to 1973. He specialized in farm machinery and power as a major in agricultural engineering. After graduation from IIT, he worked as a full-time volunteer with the Front for Rapid Economics Advancement (FREA) , India to organize and manage an agro-service center to its Patoda base self-supporting. In 1974, he joined the International Crops Research Institute for the Semi-Arid Tropics (ICRISAT) , India, where he had the opportunity to work with professionals from different part of the world. As an Agricultural Engineer of the Farming Systems Research Team of the ICRISAT, he designed and developed agricultural implements for the improved farming systems developed at the ICRISAT. The adaptation of a traditional bullock cart to a animal-drawn tool carrier made such a technology within the economic reach of Indian farming community. 225

PAGE 237

226 He then moved to Brazil in 1979 to work for the Interamerican Institute of Agricultural Science (IICA) as a Mechanization Specialist. He was stationed at the Center of Agricultural Research for the Semi-Arid Tropics (CPATSA) of the Brazilian Enterprise for Agricultural Research (EMBRAPA) and had the responsibility to organize and conduct mechanization program. The W-shaped soil management system, developed as a part of his research efforts, provided a tillage technique to stabilize and increase the production of arid northeast Brazil and other similar regions of the world. His research has resulted in over 20 publications in refereed journals from different parts of the world. The desire to upgrade his qualifications and to learn modern techniques in agricultural engineering brought him back to school in 1986 for his Ph.D. The University of Florida (UF) was the choice because of its location in a tropical climate and a flexible curriculum in the Agricultural Engineering Department and a strong program in systems research. At UF, he concentrated in system engineering, learned about AI and simulation techniques and applied them to farm systems as demonstrated in this dissertation. He is married with Chitra and has three daughters Bhawna, Monika and Prerna. He plans to find employment where he can enhance his recently acquired understanding about knowledge and systems engineering and make use of his past experience.

PAGE 238

I certify that I have read this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. Dr. R. M. Peart, Chairman Graduate Research Professor of Agricultural Engineering I certify that I have read this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. Dr. W. D. Shoupf, Cochairman Professor of Agricultural Engineering I certify that I have read this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. rotessor of Agricultural Engineering I certify that I have read this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. Drr^Peter Hildebrand ^-— . Professor of Food and Resource Economics

PAGE 239

I certify that I have raad this study and that in my opinion it confirms to acceptable standards of scholarly presentation and is fully adequate, in scope and quality, as dissertation for the degree of Doctor of Philosophy. Dr .'^Douglas D. Dankel Assistant Professor of Computer and Information Sciences This dissertation was submitted to the Graduate Faculty of the College of Engineering and to the Graduate School and was accepted as partial fulfillment of the requirements for the degree of Doctor of Philosophy. December 1989 Dean, Graduate School

PAGE 240

r, 'if^ n Q^