Computers and Electronics in Agriculture, I (1986) 125--141 125 Elsevier Science Publishers B.V., Amsterdam -- Printed in The Netherlands

D E V E L O P M E N T OF A P R O T O T Y P E F A R M I N F O R M A T I O N M A N A G E M E N T SYSTEM

ROBERT KOK and LAURENT GAUTHIER

Agricultural Engineering Department, Macdonald College, Ste. Anne de Bellevue, Que. (Canada)

(Accepted 15 August 1985)

ABSTRACT

Kok, R. and Gauthier, L., 1986. Development of a prototype farm information manage- ment system. Comput. Electron. Agrie., 1 : 125--141.

A sophisticated database management system was used to design and implement a farm information management system. The package was installed on a microcomputer and its potential as an on-farm management tool was investigated. Several programs supporting database maintenance and querying were developed, implemented and tested. The system was designed to be very user-friendly. Data representing 2 years of actual farm operations were entered. The prototype system was found to be flexible and expandable.

INTRODUCTION

Farmers , like all managers , are cons tan t ly making decisions. To a large ex ten t t hey rely for guidance on in tui t ion, exper ience, insight and t radi t ion ra ther than any s t ruc tured or analytical process. This is because the ' knowledge ' or i n fo rma t ion required to proceed in a to ta l ly rat ional manner is of ten t oo r e m o t e or t oo diffuse to make use o f or because the task of analyzing the in fo rmat ion is too t ime-consuming and /o r compl ica ted . Compute r s can be used to store and mainta in a 'knowledge-base ' to assist in the decis ion-making process on the farm. Such a knowledge-base might consist of an on-line database, a database m a n a g e m e n t sys tem (DBMS) and a high-level p rogram package with an inherent capaci ty to ' learn ' and to suppor t unforseen demands . The con t inuous ly increasing sophis t icat ion and accessibility o f m i c r o c o m p u t e r hardware and sof tware is bringing such systems wi th in reach of small businesses and individuals.

Agricul tural enterprises have un ique and demand ing requi rements tha t mus t be addressed by the designer of any system in tended for on-farm applications. The user-interface mus t be very ' in tel l igent ' and to ta l ly f r i e n d l y The system should be modula r , given the very diverse and dynamic nature of the farming env i ronmen t , and mus t be robus t (i.e., resistant to user errors.,

0168-1699/86/$03.50 © 1986 Elsevier Science Publishers B.V.

126

accidents, etc.) in view of the often extreme operating conditions for both hardware and software. Only on-farm computing power, in the form of a microcomputer system in which a large and comprehensive database is integrated, can fulfill these criteria since microcomputers offer fast response time and dependability and are easily upgradable and maintainable. They can also support a large array of devices for graphics, sound, communications, mass storage and automatic data acquisition and control.

A knowledge-base integrates rules (or models) and data which together can be used for process control, decision support, diagnosis or design. As the 'knowledge system' acquires experience, more data can be used and the rules can be refined. The farm computer system can thus become a tool that complements and assists the manager in areas where he is most limited: acquiring, remembering and processing large quantities of discrete data. The design and implementation of 'intelligent' computer systems is still in a very primitive stage. Much work has yet to be conducted in areas such as knowledge representation, pattern recognition and human-machine interfaces (Albus, 1981). Nevertheless, this technology is becoming available and an effort to implement it in the agricultural sector was made.

In this project, existing microcomputer software and hardware technology were used to create a prototype farm information management system. The focus of the effort was on the design and implementation of a large and comprehensive database and a user-friendly program package. A database containing primarily data on the field operations of the campus farm (110 animals) was defined and structured using an 'extended network' type DBMS. The program package consists of a 'user-friendly' interface and routines to support data entry and editing as well as database querying and report generation. The package and the DBMS were installed on an IBM XT computer. A representative amount of farm data, covering two years of field operations on the campus research station, was entered into the database and extensive report generation was carried out.

LITERATURE REVIEW

The use of electronics and computers in agriculture and in farm manage- ment is attracting more and more the interest and imagination of the agricultural community. The utilisation of computers in ' information systems' is considered by many authors to be the key to any further increase in farm productivity (Black et al., 1981; Peart and Puckett, 1982; Sonka, 1983). Robson (1982) has pointed out the "diff icul ty in finding accurate figures for use in budgeting" as one of the major problems in farm management. He outlined a 'farm information system' and listed the hardware and software requirements for the successful implementation of such a system.

In this paper is discussed a system used for physical recordkeeping, planning and decision support. Recordkeeping consists of gathering and

127

organizing information concerning physical entities on the farm (fields, animals, machines). Automated recordkeeping increases the total amount of information available to the farmer. This allows him to use what Peart and Puckett (1982) call a 'management by exception' approach where one manager can effectively handle a large farm by concentrating his at tent ion on the problem or exceptional cases. The data can be acquired automatically and used for various control functions (robotics). Currently available decision support programs are of very limited scope. The bulk of these programs are for computing least cost rations for livestock (Strain and Fieser, 1983). These and other packages are intended to help solve a very specific and short- lived problem and thus do not constitute legitimate decision support systems as described by Keen and Morton (1978). A decision support system must be able to draw on a large and accurate source of information in order to be effective. It must also be totally flexible in both its input and output . Existing farm planning functions often consist of cost benefit analyses given different marketing scenarios (Homestead Computer Services Ltd.~ 1983) but do not generally support the scheduling and planning of farm operations like crop rotations, tillage, seeding, spraying, harvesting, culling etc.

Database management systems (DBMS) are essentially computer-based record keeping systems (Date, 1981) which enhance the efficiency and effectiveness of the data storage and maintenance task. A DBMS can be used to store and access information considered of importance to the decision making process or management of an organization. The DBMS primary function is to shield the user or programmer from the details of the physical data storage and to maintain a logical ordering of the data. Application programs that give the user access to the data can change or be added to the system without requiring any change in the data structure. This is referred to as data independence and data sharing. Another characteristic of a data -~ base system is data integration. This can be thought of as the unification of otherwise distinct files with any redundancy between files partially or totally eliminated. This leads to increased security and reliability. If no, or very little redundancy exists, consistency and data integrity are much more easily controlled. A full-scale DBMS usually supports different host languages. This means that an application programmer can write a program to manipulate the database in e.g., Cobol, Fortran, BASIC, or C depending on the particular task and on his particular skills.

In Robson's (1982) view, the key to the success of on-farm computerized systems is "effective modular programs that, while allowing for once-only input of data, hold data in storage in an economical form." It is our belief that the best way to attain this is through the use of a BDMS.

SYSTEM COMPONENTS

The computer used for the project was an IBM XT with 512 Kbytes of read/write memory. Two video displays were installed on the machine, a

128

monochrome and a color graphics screen. Mass storage devices were two mini f loppy disk drives and one 10-Mbyte fixed disk. The printing device was an Epson MX-100 dot matrix printer, 132 columns wide with graphics capability. The operating system used was IBM PCDOS version 2.0. It is a single-user, single-tasking system.

As for many software packages, the one described herein consists of several distinct components . These components are described below in terms of their characteristics and roles in the overall system.

The database management system, MDBS III, was acquired from Micro Data Base Systems Inc. It is a full-scale DBMS and is supported in different software and hardware environments. MDBS III has an ' ex tended ' network architecture described by Holsapple (1980a, b). In a network database, the four elementary constructs are areas, fields, records and sets. The database is composed of one or more areas, each one identified by a unique name. A record is an assembly of related fields (also called data items) while a set is used to link two or more record types together. The structure of the database is defined by a 'schema' which essentially specifies the various record types and sets used while the stored data consists of record and set occurrences. In the sample schema given in Fig. 1, record types are repre- sented by rectangles with the associated data items inside. Sets are represented by arrows pointing from the owner to the member. The SYSTEM record type is an empty record occurrence which provides access to o ther record occurrences through system-owned sets (e.g., SYSPARCEL, SYSCROPS). An occurrence of the record type PARCEL contains the parcel name and surface area, a TREATMT record occurrence contains the t rea tment type, quant i ty applied, and date of the operation. Each PARCEL occurrence can be linked to one or more TREATMT occurrences through occurrences of the set TREATED. In a schema, as many sets as necessary can be specified. Owners and members of a particular set can be sorted, based on various clauses (LIFO, FIFO, ascending/descending item etc.). Thus, if required,

SYSTEM SYSPARCEL

PARCEL

PNAME ~ SEEDED PAREA I

TREATMT

TREATED ~ TREATID QTY

- DATE

Fig. 1. A sample database schema.

I sYSCRQP

' 1 CROP

CROPID

SEEDRATE

YEAR

129

parallel sets linking the same record types can be defined with a different sort clause for each one. In Fig. 1, the PARCEL and CROP record types are linked by a many- to-many set called SEEDED. One PARCEL occurrence can have many CROP member occurrences (one per season for example) and any CROP occurrence can be linked to several PARCEL occurrences (e.g., the same crop can be grown on several parcels). The database can be defined across several areas, each one corresponding to an operating system file and each record type can be assigned to a unique area in the database.

To specify the database schema and organization, the designer uses the DDL (data definit ion language) processor (MDBS, 1981a). This program analyzes a source code file (written in a free format , English-like language) for syntax and logic errors and subsequently initializes the database. The initialization step creates all the database files with the necessary system pages.

Once the database is initialized, data can be inserted and edited. This is generally done with the data manipulation system (DMS) described by MDBS (1981b). To the application developer, the DMS appears as a library of :functions or subroutines which are used to navigate through the database and to transfer data to and from it. These functions return a status code to the calling program and thus allow for trapping of unforeseen events. The functions are called f rom within a host language (Basic, Fortran, C, Cobol etc.) so that the data is transferred from a host language data structure to the database or vice-versa via the DMS. In such an environment, the appli- cation programmer can completely insulate the end-user from the logical and physical organization of the database. Access mechanisms become transparent and the end-user merely interacts with a program package through an inpu t /ou tpu t device -- typically a screen terminal.

T A B L E 1

Screen Master f u n c t i o n keys w i th c o r r e s p o n d i n g IBM PC keys t rokes

F u n c t i o n IBM PC Descr ip t ion n a m e k e y s t r o k e

F A B O R T Esc or F4 F D E L E T E Del F E N T E R E n t e r ( r e t u r n ) F H E L P F1 F I N S E R T Ins F L E F T L-arrow F N E X T tab or D-arrow F P R I O R S-tab or U-arrow F R E S T A R T F2 F R I G H T R-ar row F Z A P Backspace

a b o r t f rame inpu t delete cha rac t e r u n d e r cursor f rame inpu t c o m p l e t e d he lp t e x t toggle inser t b l ank cha rac t e r u n d e r cursor move cursor lef t in f rame tab to n e x t f rame tab to pr ior f rame res ta r t f r ame i n p u t move cursor r igh t in f rame des t ruc t ive backspace

Note : U, up ; D, d o w n ; L, lef t ; R, r ight ; S, shift .

130

To keep the information displayed on the screen separate from the application program, a screen formatter was used. This software, called Screen Master, also from MDBS Inc. (MDBS, 1982a, b) is fully integrated with the DBMS. It allows the definition of screens containing titles, frames for input /output , on-line help and menus. The designer controls the color, position and other attributes of each element. The screen dictionary is created using the Screen Definition Language (SDL) which inserts the definitions into the main area of a database. The application programmer can then access any screen through the Screen Manipulation System (SMS) which closely resembles the DMS in its operation.

To the end-user, the system is completely cursor oriented. In total, up to

~ j=now'edge 1 --|of opplicationJ

r . . . . . . . . . . -t- . . . . . . . . . . - t ~ ] database I I = ~ = ' ~

[ sol [ T M I sA=coM

l LINK

application program DMS / SMS commands language specific interface

J DMS/SMS I

load module

DMS~SMS ] ~resident DMS/SMS

o.,. i o . , . - .

' t

runtime environment

---e,~knowledge flow ---~data flow

Fig. 2. Prototype development process. ==~ control flow

131

ten unique keystrokes may be used to perform functions such as moving the cursor, selecting a menu option, entering data, jumping from frame to frame inside a window, asking for help, aborting the current process and deleting or inserting characters. A list of the various keystrokes and their corresponding functions is given in Table 1.

The host language used for this project was Microsoft Inc.'s BASIC compiler (BASCOM) version 1.0. In BASCOM, the DMS/SMS functions are invoked through a BASIC 'CALL' statement as described by MDBS (1983). At the link-editing step, the external references are resolved by linking the BASCOM object file with an MDBS III language specific library {also in object format).

In the hardware/software environment used, the actual DMS/SMS routines are loaded into low memory at power-up and DOS is made aware of their presence so they will not be corrupted. During program execution, control is passed to the resident routines through a software interrupt mechanism. This allows the actual object library linked with the BASIC program to remain small (5.4 Kbytes) since it merely contains references to the DMS/SMS routines located in the resident module. The overall sequence of events in the development of the system is illustrated in Fig. 2 while in Table 2 is shown a memory map of the system operating under PCDOS 2.0 with 512 Kbytes of core memory.

TABLE 2

Memory map of package runtime environment

Hex. Address Dec. Address Description (in paragraphs) (in Kbytes)

0000 0 K O8OO 32 K 1000 64 K 4000 256 K 4C81 316 K 5000 340 K

DS: 0000

8000 512 K

Interrupt Vectors and DOS area Print Spooler (bottom of user area) Virtual Disk DMS/SMS code DMS/SMS data BASIC CODE (compiled program) Runtime & Constants (data segment) COMMON Assembly Language subroutines (BASIC-DMS interface) BASIC variables String Space File buffers user stack BASRUN.EXE .EXE loader (top of user area) top of memory

132

~1~ j"LI i

IJ ~

J o Ill *,--~ I e l , l- 11 . ,~

= - z

~lttz~

133

PROTOTYPE SYSTEM DESCRIPTION

The database, as defined in the p ro to type , was conceptual ly divided into four major partitions: (1) permanent data -- informat ion that seldom changes (on the average less than once a year), (2) annual data -- informat ion that can be linked with a particular cropping season or administrative year, (3) daily data -- informat ion on daily farm operations, and (4) inventory d a t a - - informat ion on farm stocks and suppliers. The complete data schema is presented in Fig. 3. The first part i t ion includes the record types USER, FARM, FIELD, TRACTOR, MACHINE, STRUCTURE, SOILTYP, DRAIN, CROPCON and DEPT. The informat ion stored in these records is intrinsically associated with the record type. For example, a FIELD record occurrence contains the name of the land parcel, its surface area, stoniness, boundaries, slope and year. The USER record is used to moni tor the database activity of the various users. An occurrence of USER contains information such as the name, access code, complet ion code and last logon time and date for one user. The CROPCON record type can be used to store different categories of crop contraints such as drought, disease and winter-kill that might inhibit product ion. The record types which belong to the annual data part i t ion are FUNCTION, SEASON, CROPS, SOILANA, CROPANA, CONOCC, INSUR and PLOT. They are used to store data for a given year (e.g., CROPS -- name and seeding rate of crops grown this year) or to characterize a record occurrence belonging to the permanent category (e.g., SOILANA -- the results of a soil analysis for a particular field). Daily data record types are TREATMT, TILLAGE, HARVEST and MAINTCE. They are used to maintain a log of all transactions affecting fields, plots, tractors, machinery and farm structures. For example, a TILLAGE record occurrence consists of the tillage date, number of manhours and type of operat ion (it can be linked to a specific field record occurrence and to t ractor and machine occurrences). Inventory data is organized into major- and sub-accounts represented by the record types PCLASS and PRODUCT. A major account occurrence could be ' feed ' having an associated subaccount occurrence 'alfalfa haylage'. A SUPPLIER record type is also defined and allows storage of the supplier names and addresses. The relationship between partitions, areas, record types and files is shown in Table 3. The records belonging to the annual or daily partit ions are assigned to an area based on their data value.

In order to bet ter illustrate how informat ion is represented in the data schema of Fig. 3, a typical field operat ion is examined: the farmer has treated a field with a pesticide using a t rac tor and a spraying implement. The information is then recorded in the following fashion: the date, type of t reatment , total quant i ty applied and number of manhours are stored in a TREATMT record occurrence. This occurrence is then linked to a FIELD occurrence through the set TREATED and to TRACTOR and MACHINE occurrences through the set WITH. It is also linked to a PRODUCT occurrence through the set USES. All these operations are made transparent to the

134

TABLE 3

Database partitions, record types and files

Partition Area File name Record-type

PERMANENT PERM PERM.DBA USER FARM SEASON FIELD FUNCTION MACHINE TRACTOR STRUCT DEPT SOILTYP DRAIN CROPCON

INVENTORY INVENT INVENT.DBA PCLASS PRODUCT SUPPLIER

ANNUAL TRANS81--TRANS87 a TRANS81 .DBA-- PLOT TRANS87.DBA b CROPS

SOILANA CROPANA INSUR CONOCC

DAILY TREATMT HARVEST MAINTCE TILLAGE

aOne A R E A per year. b One fi le for each A R E A .

end-user w h o is m e r e l y p r o m p t e d fo r the raw da t a b y the app l i ca t ion p rog rams . The s y s t e m compr i se s several i n d e p e n d e n t modu le s which are ove r l ayed

at r un t ime . This s implif ies package design and m a i n t e n a n c e and pe rmi t s fu tu re g rowth . The basic h i e ra rchy t h a t was devised is s h o w n in Fig. 4. A t r ansac t i on logging ut i l i ty was des igned in to the sy s t em and is used to m o n i t o r s y s t e m s ta tus , use and p e r f o r m a n c e . The p r o g r a m package m a k e s use o f several levels o f e r ro r t r app i ng in o rder to recover or flag user and p r o g r a m incons is tenc ies or ha rdware ma l func t ions .

One o f the ma in p r e o c c u p a t i o n s in t he design o f the user in te r face was to keep it cons i s t en t and easy to ope ra t e b y naive users whi le ma in ta in ing a r easonab le level o f e f f ic iency . The s y s t e m is designed to min imize b o t h k e y b o a r d use and the o p e r a t o r ' s m e m o r y load. The pe r sona l i ty of the user in te r face was ve ry m u c h c o n d i t i o n e d by the Screen Master d isplay and k e y b o a r d drivers. All f unc t ions are m e n u driven, on-l ine he lp is available m o s t o f t he t ime and m a n y p r o m p t s , messages and p ic tu res are used to

135

enhance user orientation. The user navigates forward through the system by selecting a menu option. To recall the previous menu, exit a module and eventually exit the system, the user must hit the 'Esc' key in response to a prompt for a menu selection or for data. This is the only way to reverse or abort a process. The package behaves according to the skill and experience of the user. A special record type in the database (USER) is used to keep track of user status, experience and performance.

program levels

DBMS { MODULE

I AUTO - I EXECUTING FILE

e z _ ~ LOGON I / / "~ ~,s & r--- -" 'LLOG F,LE,)

MAiNMENU I- ..... 2 ..........

MODULE i A ~-- ~ MODt MODULE B

i ; ' i = Y

, ~ SUB A.]

system communication files utilities

SUB A,2

SUB A.i

i i r I

DMS /SMS

DATABASE

SUB B.3

SUB B.2

SUB B.1 ]

__] COMM5

LOGGING

ERROR HANDLING

I CHAINING

control flow - - - ~ d a t a flow

Fig. 4. Program package hierarchy and control flow.

DESCRIPTION OF PROGRAM MODULES

The program package as developed for this project consisted of modules and submodules linked together in a hierarchical fashion. One module , called LOGON, was used to enter or exit the system as well as to branch to the other modules through a main package menu. The UPDATE module , together with its associated submodules, served to modify and maintain the database

136

while the REPORT module was designed to query the database and produce typewri t ten and graphic reports.

The database update module was the most difficult and challenging software subsystem to design. In a system like the one considered, the complexity and size of the database poses several maintenance problems. To a large extent, the system's data structure must be hidden from the user in order to project a consistent and unified view of the information's organization. Essentially, the designer must decide how to implement and group the insertion, deletion and editing functions. In a network structure as used in MDBS III, there are five basic operations that result in a database modification: (1) record creation -- adding a new record occurrence of a certain type (DMS create commands), (2) record update -- changing the contents of one or more fields of an existing record occurrence (DMS modify commands), (3) record deletion -- erasing a record occurrence from the database (DMS deletion commands), ( 4 ) r eco rd c o n n e c t i o n - inserting a record occurrence into a set, making it either an owner or member of that set (DMS connect commands), and (5) record disconnection, removing a record occurrence from a set, disconnecting it from a member or owner of that set (DMS disconnect commands). The database update module thus serves as an interface between the user and the DMS for all of the above operations.

Following are a few sample questions that confronted the designers during program development. How much and what should the system assume about the structure and composition of a given transaction? For example, did a field operation require one, two or more tractors and one or more implements? What products, if any, were applied? Should the inventory be updated accordingly, and if so, should it be done automatically? Should the record creation and updating (modification) functions be grouped together? If a transaction involves several record occurrences, how is the editing of that transaction to be provided for? Should the user always decide ahead of time what information needs to be stored or should the system adapt and react to the existing database contents by flagging context-sensitive alternatives? When connecting two records, should the program allow the user to create a new record before inserting it in a set? If not, what happens? The under- lying issue is thus one of balancing ease of use with flexibility. The approach taken throughout the module design was to give the user ultimate control and arbitration over the extent and composition of the information to be inserted in the database. The user does not require any knowledge about where and how the data is actually stored and maintained. However, the programs will always make the operator aware of precisely what information is being stored. The user is continuously prompted by the program which attempts to obtain the most complete and accurate information but the human operator can always override or ignore a request or message and even rollback (undo) any given transaction. The update module was functionally divided into submodules corresponding to the type of data: permanent, annual, daily and inventory.

137

For any information management package a good, general-purpose data retrieval system is essential. One must be able to quickly and easily access the database and produce meaningful reports, displays or listings. The optimal or 'best ' choice of user-interface is a function of the type and sophistication of the user as well as the environment in which the application is destined to be used. For a sophisticated user a command language is probably the most effective approach but it becomes very difficult to conceal the underlying database structure. Thus, there is a trade-off between flexibility and ease of use. For more naive users a menu-driven application is essential. Obviously, the designer cannot provide menus to handle every possible or imaginable query. The number of query possibilities increases with the complexity of the database and a menu-driven application quickly becomes unmanageable, if at all feasible. The alternative is to design several report generation programs that allow only certain parameters to vary. The programs thus remain simple (from the user's perspective) while still offering a certain degree of output customization.

The latter approach was used in the design of different programs which allow the user to query the database in a piecemeal fashion. These programs were developed in order to illustrate the possibilities of the system and do not constitute a complete or comprehensive set. They are menu-driven and thus provide quick and straightforward access to the database contents. Two of these programs produce written reports which can be displayed on the console, sent to a printer or saved in a file.

8

7

6

5

4

3

2

I

a b c (t e f 9 h i ,j

H a c c l [ o n a 1 ct R e s e a x ~ c h S t a t i o n

.... ,i i :ili

~~'-:"~" i[ ................... ~ .......

~'i -~~::' 1984 Cx,,o ps iiiiiiiiiii R' ' INCOmS 'I"L' 'CrE C'm"rBA RLEY .................. E: I OTHER .........

Fig. 5. Sample output from submodule FMAP.

138

The color graphics capability of the microcomputer was used to produce maps of one or more fields whose boundary coordinates are stored in the database. Additional information such as field crops can be color coded onto the map and the screen can be dumped onto a dot matrix printer (a sample map is presented in Fig. 5).

In the above applications, the information retrieval function is explicit and deliberate. In the future however, other applications will access and use information from the database in a way which will be totally transparent. The goal will be to further isolate the user from the data structure and to approach more closely the 'knowledge-base' paradigm.

RESULTS AND DISCUSSION

The system described was used to store and maintain a database for the Macdonald College Research Station. In the initial implementation phase 300 Kbytes of data, representing two years' of farm operations were entered (1983, 84). The information was collected from existing farm records, bills and maps and from slips filled out by research station employees after each day's work. These slips normally specified the date, type of operation, field number, machine a n d tractor codes, product(s) used and employee name. All these data were collected, interpreted and inserted into the database by undergraduate students during the summer months. An estimated 400 h were invested in these activities resulting in the creation of about 1200 record occurrences and about 2000 record connections (links). The system maintenance time requirements during the busy season was evaluated as varying between 1 and 2 h per week. As expected, the task of entering data for previous years was complicated by the difficulties encountered in obtaining complete and accurate information and by the fact that the persons in charge of collecting and entering data were not totally familiar with the operation of the research station. To ensure a smooth operation and data integrity and quality, a weekly maintenance session by a member of the regular farm staff was found to be a minimal requirement and anything approaching a daily session was considered to be ideal.

Early in the project, it became apparent that a fast, high capacity, mass storage device was needed to run the package and to develop the programs. This proved to be a just evaluation since the database as initially defined can occupy up to eight f loppy diskettes (2.8 Mbytes) with the screen dictionary occupying more than one diskette (380 Kbytes), and the program package being 320 Kbytes in size (one diskette). The shuffling of floppy diskettes was considered to be a totally unfriendly approach and the data transfer rate of floppy disks inappropriate for the kind of software system considered. The 10-Mbyte fixed disk used was fast and large enough for both package operation and software development. Overall, the hardware performed satisfactorily throughout the project and proved to be reliable and powerful enough for all functions investigated.

139

The MDBS III system performed well and was found to be a very robust and mature package. A schema restructuring utili ty would be of great value and would complement an otherwise very complete package. The screen formatter provided a consistent and professional user-interface as well as a good way to keep user-information separate from the application programs. The approach is worth retaining but a leaner system which relies more heavily on the application program would provide a more productive software development environment while giving the programmer more control over the personality of the user interface.

The BASIC compiler performed flawlessly at all times and its speed and error recovery were its most visible assets. Nevertheless, BASIC was not a natural environment for the kind of software system considered; the lack of support for separately compiled object modules, record data structures, local variables and true parameter passing to subroutines constitute severe liabilities in a large software development project. A systems programming language such as C would be preferable.

The perfect balance between flexibility, efficiency and ease of use is very difficult to strike when designing database editing programs. Only through extensive testing can one hop to 'fine tune ' the editing routines. Preliminary results suggest that the programs could be made more effective and efficient by reducing the amount of screen movement and removing, whenever possible, menus and prompts which are redundant. Nevertheless, the programs were found to be reliable and easy to use, requiring a minimum of training in computer operation as well as in farm data organization.

SUMMARY AND CONCLUSIONS

The use of on-farm microcomputers and electronics for management, monitoring and control functions is a vast and wide open field. This research has focused on the design and implementat ion of a farm information manage- ment system using a microcomputer and a sophisticated database manage- ment system. The principal objectives were to evaluate the effectiveness,, potential and appropriateness of this technology in today's environment as'. well as to gather the necessary criteria for the design of future systems.

The use of a DBMS and screen formatter was successful and has been found to enhance the system's friendliness, flexibility, speed, adaptability and modularity. Once the initial database design was finalized, development time for applications was short and the whole process fairly straightforward. A more sophisticated operating system, especially one that supports multi- tasking, would enhance and improve system design and would be very helpful to integrate data acquisition and control functions. This integration was found to be highly desirable as it would provide more accurate, precise and abundant data and would make the system friendlier and hence, more acceptable to potential customers. For example, an electronic pass-thru

140

weighing scale could be used to record the weight of a forage box or manure spreader for all harvesting, and fertilizing operations. This information, along with appropriate operator input could be logged in real time into the main farm database through a terminal located at the weighing site.

Observers see electronics as one of, if not the most significant technological development to affect agriculture till the end of the century (Isaacs, 1982; Peart and Puckett , 1982; Pejsa, 1983). As costs decrease and hardware and software get more sophisticated, intelligent robots will appear on the farm, probably as soon as 1990 (Pejsa, 1983). Farm management systems will be able to take over some of the managers' tasks and will serve as decision support systems in the areas not ready or fit for automation. Farms will continue to get bigger and use less manpower (Krutz, 1983). They will be on-line with the outside world both as receivers and transmitters of information. The farm manager will be able to operate his computer system with minimal training and on-farm computer systems will be used to acquire, store and interpret farm data as well as control a growing number of farm processes and operations. Electronics are invading practically all areas of farming but at tempts to integrate and to network all the various devices and components are still embryonic. This functional integration will enable the development of truly 'intelligent' farm management systems which will provide the farm manager with a large array of powerful decision-making tools. As Peart and Puckett (1982) describe it, "...it is the total farm manage- ment system which is going to be of ultimate benefit to our farmer-cus- tomer" .

For the near future, applications aiming to increase productivity and to schedule operations are envisaged. These have the potential to considerably enlarge the scope and usefulness of a 'knowledge-based' system as well as to extend the 'art ' of farm management. Essentially, technologies such as the one discussed in this paper aim to extend the capabilities and 'in- telligence' of the farm manager. Tomorrow's farm managers will have access to powerful decision-making and executing tools which will enable them to concentrate on the planning, rationalization and refinement of farm opera- tions rather than on their execution.

ACKNOWLEDGEMENT

The authors gratefully acknowledge the financial assistance of the Conseil des Recherches et Services Agricoles du Quebec.

REFERENCES

Albus, J.S., 1981. Brains, Behavior and Robotics. Byte Books, McGraw-Hill, New York, NY, 352 pp.

Black, J.R., Waller, J.C. and Brook, B.C., 1981. The development of software for

141

computer-assisted agricultural decision-making. ASAE Pap. 81-5039, American Society of Agricultural Engineers, St. Joseph, MI, 26 pp.

Date, C.J., 1981. An Introduction to Database Systems (3rd Edition). Addison-Wesley, Reading, MA, 574 pp.

Holsapple, C., 1980a. A primer on database management systems. Micro Data Base Systems, Lafayette, IN, 54 pp.

Holsapple, C., 1980b. A guide to database management. Micro Data Base Systems, Lafayette, IN, 43 pp.

Homestead Computer Services Ltd., 1983. The Homestead farm management system. Winnipeg, Man., 7 pp.

Isaacs, G.W., 1982. The electronic age in agriculture. Agric. Eng., 63: 8. Keen, G.W. and Morton, M.S., 1978. Decision Support Systems, An Organizational

Perspective. Addison-Wesley, Reading, MA, 264 pp. Krutz, G.W., 1983. Agricultural robots and social issues. Agric. Eng., 64: 17--19. MDBS, 1981a. MDBS data base design reference manual (MDBS-DDL), V3.06, Revision

83b. Micro Data Base Systems Inc., Lafayette, IN, 96 pp. + appendices. MDBS, 1981b. MDBS application programming reference manual (MDBS-DMS), V3.06,

Revision 83b. Micro Data Base Systems Inc., Lafayette, IN, 118 pp. + appendices. MDBS, 1982a. Screen design reference manual (Screen-SDL), V1.02, Revision 83b.

Micro Data Base Systems Inc., Lafayette, IN, 102 pp. + appendices. MDBS, 1982b. Screen application programming reference manual (Screen-SMS), V1.02,

Revision 83b. Micro Data Base Systems Inc., Lafayette, IN, 70 pp. + appendices. MDBS, 1983. MDBS III system specific installation manual for MSDOS/PCDOS and

BASCOM86, V3.06, Revision 83b.Micro Data Base Systems Inc., Lafayette, IN, 38 pp. Peart, M.R. and Puckett, H.B., 1982. Feed processing and animal feeding: "management

by exception". Agric. Eng., 63: 18--19. Pejsa, J.H., 1983. Agricultural robots and economic issues. Agric. Eng., 64: 15--16. Robson, F., 1982. The development of farm based computerised information systems

in the United Kingdom. In: R.E. Kalman and J. Martinez (Editors), Computer Appli- cations in Food Production and Agricultural Engineering. Proc. IFIP TC5 Work. Conf. Food Production and Agricultural Engineering, Havana, Cuba. North-Holland, Amster- dam, pp. 283--298.

Sonka, S.T., 1983. Computers in Farming, Selection and Use. McGraw-Hill, New York, NY, 266 pp.

Strain, J.R. and Fieser, S., 1983. Updated inventory of agricultural programs available for extension use. Cooperative Extension Service, University of Florida, Gainesville, FL, 186 pp.