Marvin L. Stone and Mark Zachos

Oklahoma State University Dearborn Group

Stillwater, Oklahoma Farmington Hills, Michigan

Summary:

A strategy is presented for developing a message set that could allow SAE J1939 to be used with construction and agricultural implements. The paper is intended for use as a guiding example for development of message sets for implements for J1939. The message set forms the necessary addition to the applications layer in J1939 to allow it to be used for a particular implement. A message set for agricultural sprayers was developed as a part of this paper and could serve as an initial document for a committee developing a message set for sprayers. Generation of applications layer documents for implements should be a natural function within ASAE. The work done at ASAE in this area should form a significant part of the expertise that can be provided to the ISO TC23/SC19/WG1 in developing the network applications layer for implements for an ISO standard.

Introduction

The critical need for a standardized electronics communication protocol for agricultural equipment was recognized as early as 1986 at ASAE (Bernard, 1986). In-vehicle networks were being developed earlier for on-highway systems and included the Society of Automotive Engineers (SAE) recommended practices J1708 and then J1587 in on-highway trucks and J1850 in automotive applications. J1587 is currently being used in both truck and bus and construction equipment applications (Luebbering and Smith, 1993). J1587 is currently in use in agricultural equipment and may be the earliest standardized in-vehicle network used in these applications.

Focused efforts by the US construction and agricultural equipment industry to participate in development of a US and an International standard were begun in December 1992. Earlier that summer, the first meeting of the International Standards Organization working group for mobile agricultural electronics, ISO/TC23/SC19/WG1, was held and focused on development of an interim standard for communication between tractor and implement. The initial work defined a connector with frequency and analog based signals. In addition, a proposal based on a developing DIN standard was presented by the German experts. The ISO activity instigated action by the US industry and by summer of 1992, a US proposal was added to proposals from Germany and the UK at the ISO working group (Stone and Zachos, 1992). The CAN (Controller Area Network) 2.0b (Bosch, 1991) based SAE J1939, an SAE draft recommended practice for heavy-duty vehicle networks, has now been endorsed by the Joint ASAE and SAE committees responsible for developing network protocol standards for agricultural and construction equipment (ASAE IET 353/1 and SAE ORMTC/SC32 - Off Road Machinery Technical Committee/Electronic Control and Monitoring Systems).

Currently the network protocol work has evolved and the ISO working group has adopted SAE J1939 as a working document. Provisions for construction and agricultural equipment have been added to SAE J1939. Some of the fundamental components of J1939 have been balloted and approved. Other fundamental components are expected to be approved in early 1994. The construction and agriculture components of J1939 are still in draft form as are the network management and diagonostics components.

SAE J1939

The current components of the J1939 Draft form a basis for communications within an implement and between an implement and tractor as well as communications between the implement or tractor mounted components. One un-balloted component of J1939 is a "virtual terminal" device. This component provides operator display and keyboard components and may be used on-board a tractor to provide operator interface functions for multiple implements.

Current draft documents for J1939 do not provide all of the necessary components to realize a standardized operational communication system for agricultural and construction implements. The missing component is a definition of messages that would be used to convey states within the implement and to allow the necessary control information to be communicated among implements and tractors. This component of the network protocol makes up the major part of the network applications layer. J1939 provides the structure of the messages, guidelines for creating message definitions, and methods for conveying the messages, but the message content for use on implements is currently undefined. A draft message set is available for communication of tractor related functions including, hitch, PTO, auxiliary hydraulic valves, and lighting.

A natural function within ASAE would be to generate the message definitions for implements that are used within construction and agriculture. The expertise in construction and agricultural implements exists within ASAE. The work done at ASAE in this area should form a significant part of the expertise that would be provided to the ISO/TC23/SC19/WG1 in developing the network applications layer for implements.

The purpose of this paper is to provide a description of how J1939 may be extended for agricultural implements and an example development of a message set for agricultural sprayers. Material developed in this paper could be used as an initial proposal to a committee responsible for developing sprayer message sets. In addition, the development process described here is intended to provide development strategies that might be used on other types of implements.

J1939 Support for Agricultural Implements

A necessary background for the development of a message set for J1939 based agricultural and construction implements is knowledge of the features of J1939. A brief review of J1939 features related to use with implements follows. Further information may be found in papers by Stepper (1993a, 1993b) and by Stone and Zachos (1992). Parts of J1939 are expected to be approved during the spring of 1994 and at that point standards documents would be available.

J1939 attempts to define a complete communications protocol including the physical medium, signaling specifications, message structure, topology, and parameter definitions for multiple vehicle industries. A base document in the standard for each industry defines the components of the standard that will be used for that industry. Base documents now exist for construction and agriculture, and for heavy duty on-highway vehicle industries.

J1939 is based on an OSI 7 layer model and currently defines physical, data link, network, and applications layers. Presentation, transport, and session layers are not included and not considered necessary in the current draft. In addition to the conventional OSI layers, a network management document has been defined whose function crosses all layers. A physical layer has not been selected at this time for construction and agriculture applications, though the 250 KBaud bus speed now defined for the heavy duty on-highway vehicles has been selected in the US for application in construction and agriculture. The current draft also contains components primarily to support construction and agriculture including a virtual terminal application layer.

Figure 1 shows the topology of a typical network for construction and agricultural equipment based on J1939. Two primary buses are provided, the tractor bus and the implement bus. Implement number 1 (with hatching) is shown with an implement sub-net bus which may also be used. The implement sub-net is a bus connected to the implement bus by a bridge. J1939 standardizes a network where each device on the network has an address. The address is included in the message identifiers sent from a node to guarantee that the identifiers are unique within the system. J1939 provides a flat address space for a total of 256 nodes. Of those, the lower 128 are normally used for single address devices including engine controllers, transmission controllers, hitch controllers, etc. and the upper 128 addresses are assigned in 8 address blocks for implements and trailers as shown in Table 1. An implement may include nodes anywhere on the implement bus. In the case of implement 1 shown in Figure 1, it has two nodes on the main implement bus, one on the tractor and one on the implement. This arrangement may be useful where the implement requires some specialized operator interface in the tractor.

Figure 1. Typical System Topology

Preferred addresses for implements are based on implement type. Table 1 lists the preferred block addresses for implements. In the example presented later with sprayers, the preferred address block is 224-231. The use of preferred addresses is described in the network management document of J1939 (SAE J1939/81). During initialization, an implement must claim it's preferred address. This process is intended to accommodate situations where two devices with the same preferred address are attached at the same time. This process consists of issuing an address request from the null address, waiting to assure the address that is to be claimed is not already being used, and issuing an address claimed message from the preferred address. Secondary address blocks have been provided to accommodate multiple instances of implements. In situations where multiple implements are attached, drills for example, each instance beyond the first would be addressed into secondary blocks. The method used to do this is not defined in the standard but could be done with wiring harness configuration or through programmable components on individual controllers. J1939 accommodates block address claims, allowing an implement to claim a block of addresses. This process allows the base address device in a block to claim the whole block and through the issuance of the block claim to inform the additional nodes belonging to that implement of the block that has been claimed. Each of the individual nodes may then issue a simple address claim for an address in the block. The assumption is that the additional nodes are programmed to claim an address that is an offset from the base address.

J1939 is based on the CAN 2.0b 29 bit protocol. Each CAN data frame sent over the network is composed of a 29 bit identifier and up to 8 bytes of data. J1939 defines fields in the identifier as well as the makeup of the data field. Messages in J1939 are composed of one or more CAN data frames. For messages with less than 9 bytes of data, the message is sent in a single frame. Otherwise, J1939 defines transport protocols (J1939/21) which allow up to 1785 bytes to be sent in a single message. The identifier of a single frame message includes a priority field (Priority), fields containing a code that identifies the content of the data field (Parameter Group), an optional destination address (PS_DA field), and a source address (SA).

Table 1. Address Assignments in J1939

J1939 uses two protocol data units (PDUs) or identifier field definitions to allow the optional use of a destination address (J1939/21). The two message types are a destination specific type and an extended data content type. Both types of messages are likely to be used with agricultural implements. The destination specific type is a directed message and allows a message to be sent from one source device or node to a particular destination device or node. The second type of message, the extended data content message, is not directed to a particular node but interested nodes may acquire the message based on the information contained. Only 480 destination specific messages may be defined compared to 8192 extended messages.

The data field of J1939 messages is normally composed of multiple parameters. Parameters are packed into the data field to conserve bus overhead, that is, to maximize the data field to identifier ratio in messages and to limit the number of data content descriptors needed. This limitation requires careful definition of the messages to assure that messages are composed of information that is reasonably sent at the same time from the same place.

J1939 provides the capability to communicate proprietary information. Both destination specific and extended data content types of proprietary messages are available. For these messages, the receiver must intrepret the contents of the data field based on the sender (source address) of the message. The sending node and the receiving node must be programmed with the definitions for the data field. A node receiving a proprietary message from a node other than one which it is supposed to understand must ignore the message. In this way a single manufacturer or several manufacturers can program their nodes to support proprietary communications.

Definition of Messages for Implements

Table 2. Message Definition for J1939

Element	Range/Options
Length	0 to 1785 bytes
Parameters	Define SLOT (see below)
Protocol Data Unit (PDU) Type	Destination Specific or Extended Data Content
Repetition Rate	currently 10 ms - 10 s or On request
Default Priority	0 = highest, 7 = lowest Recommended 3 = control, 6 = informational, other
Acknowledgment Method	Inherent in response to request Inherent in normal broadcast, ACK/NACK message

Table 2 identifies each of the elements that must be specified when messages are defined for addition to J1939. Length may be defined as necessary but limiting length to 8 bytes carries the advantage of not having to use the transport protocol with it's associated overhead. If the length of parameters is less than 8 bytes, consideration should be given to setting the message length to 8 bytes anyway to allow for future expansion of the message. For messages with high repetition rates (200ms or less) the bus loading they contribute is high and defining a shorter message at the cost of future expansion may be desirable.

Parameters that make up messages must be fully defined except in the case of proprietary messages. A definition of the parameter is required as well as scaling, length, offset and transfer function. Standardized ranges and offsets or SLOTs (Scaling, Length, Offset, Transfer Function) are provided in the J1939 applications layer (J1939/71). When a message is defined, the standardized ranges are preferred. In addition to the SLOT information, the sense of the parameter must be defined, that is, whether the parameter is a measured or a status value. A measured value is a parameter that is sensed and reported by an electronic control unit (network node). A status value is system state and may commonly be used within a command as a setpoint. Differentiation is necessary because some controllers may have available both a measured value, and a status value. For example, a planter controller may be able to report both an actual seeding rate and seeding rate setpoint and definition of a parameter named "seeding rate" would be ambiguous.

PDU type specifies whether an ability to direct a message to a particular node is being defined. The directed type of message (destination specific) is only needed when data (normally a command) must be sent to one or another of two devices but not to both. This type of message should not be defined if an extended data content message will suffice due to the limited number of destination specific messages that can be defined.

Repetition Rate for messages must be defined and guidelines for implements are not currently specified in J1939 drafts. Bus bandwidth consumption is critical in defining a message set for an implement. The maximum bus loading target for J1939 is currently approximately 30%. This calculation is based on the current message set and assumes all of the messages exist on one bus. In an implement tractor system, the tractor bus will be isolated from the implement bus by a bridge. With this configuration, some of the messages that exist on the tractor bus are not of interest on the implement bus. For example, the engine to transmission commands are likely not to be needed on the implement bus. In the same way, communications between an implement and devices on the implement bus that are on-board the tractor (see Figure 1., implement no. 1 where one node of the implement is on-board the tractor) are probably not of interest on the tractor bus. It makes sense for the bridge between the tractor and implement to filter messages and only pass the necessary messages between the buses. This function is currently supported in J1939 and is described in the network layer document (J1939/31).

Bus load calculations from an implement point of view may be based primarily on the messages that are of interest to the implement. The 30% maximum load target now used in J1939 is desirable for the implement side of the bus also. The current addressing strategy for J1939 normally accommodates up to 16 implements. Total bus load for an implement should not exceed about 2% if a maximum number of implements are to be connected. The 2% level could be exceeded in systems where the nature of the implement assures that the combined loading will not exceed the targeted maximum bus load. An example of this type of system might be a semi-mounted plow with hitch control. The plow would not generally be used with other implements, and the manufacturer could specify that the implement must not be used with other implements unless precautions are taken to avoid bus overloading. Given a 2% message load for each implement, a single message with 4 bytes of data and a 10 ms update rate would use slightly more than the allowable bandwidth. Clearly, some compromises are necessary. Realistic message rates must be found, and manufacturers of implements need to specify the bus load that their implement requires.

Eight levels of message priority are available for use in J1939. Default levels of 3 for control oriented messages and 6 for informational messages should be specified (level 0 is the highest priority). Further tuning of priority may be done by manufacturers in a configured system. Studies are available to guide selection of priorities to meet message timing constraints (Wang et. al., 1992).

Acknowledgment method for a message should be specified if the acknowledgment is not inherent in a response to requests or in the state changes that are sent in normal broadcasts. J1939 (J1939/21) includes an acknowledgment message that may be used for both acknowledgment or negative-acknowledgment.

Sprayer Message Set Design

A definition of the requirements for communication support is necessary as a beginning step in the design of a message set for sprayers. We have identified five general requirements for communications support across the implement bus. These goals are to allow:

1. Support of an interface between operator and implement

2. Communications between implement and tractor

3. Information sharing between implements and between tractor and implements

4. Gathering of management information

5. Proprietary information to be passed between components on the bus

Support of an operator interface between implement and operator is provided primarily by the virtual terminal. This device provides display screens that may be secured for use by a controller on the implement. The terminal provides keyboard support as well as alarm capability. The message set developed here will assume the existence of a virtual terminal and will not address the provision of a general operator interface for implements. Some operator interface components beyond the virtual terminal may be required. Manufacturers may wish to use operator control inputs that are tailored to a particular implement and provide a more ergonomically suitable interface than a virtual terminal can provide. Devices may be placed near the operator and use a bus connection to communicate with the implement. Figure 1 shows implement no. 1 with an off-implement node in the cab of the tractor. Communications between these devices and the implement may be done through proprietary messages which are supported in J1939 (J1939/21).

Communications between implements may be useful in allowing coordination between multiple implements. The message to turn the sprayer boom off might be coordinated with a message that is generated on the tractor when the three point hitch is out of working position or raised. In the same way, if a sprayer and a granular chemical applicator are used together, a need may exist for each of the implements to know when the other is actively applying chemical. Messages that are generated by sprayers and used for coordination of multi-implement systems must be considered in a sprayer message set.

Communication between implements and tractors may be required to allow implements to provide three point hitch settings, PTO commands, and auxiliary hydraulic commands. A proposal for this message set is now before the Construction and Agriculture Multiplex Committee (Stone, 1993a) and will not be considered here. In addition, communication from tractors to implements to control lighting is needed. Another proposal for this message set is also before the Construction and Agriculture Multiplex Committee (Stone, 1993b) and will also not be considered here.

Information sharing is one of the benefits and a driving force for using network control systems. Vehicle speed is an example of shared information currently defined in J1939. Currently many agricultural tractors incorporate true ground speed measuring systems. This information can be used by implements as a primary ground speed reference. Other examples of shared information that are currently defined in J1939 include date, time, position, vehicle (implement) identification number, implement name, and outside air temperature. Access to these messages should be provided on the implement bus. Computation of bus load on the implement bus should include these messages.

Collection of management information from machinery has been envisioned as a primary function of the tractor/implement bus system in Europe. Products that allow collection of process inputs on a per field or per plot basis are under development. These systems allow planning to be done initially on a home computer. Chemical types and application rates for each field can be selected for a spraying operation. The information is then transferred to a task controller on the tractor. An operator can recall this information at the field and use the settings at the proper field. The operator can make any adjustments in the field and the actual application rates, chemical types, and timing are recorded during the operation and can be then transferred back to the home computer.

Much of the communication within an implement and some communications among components may be of a proprietary nature. No attempt will be made in this paper to identify and quantify proprietary messages.

Two areas where message set definition is needed are 1) information sharing between implements and tractor and 2) gathering of management information. The message set development that follows will address these areas.

Definition of Sprayer Entities and Parameters

A necessary background to begin development of a sprayer message set is to identify the functional components of sprayers and the relationships that exist among the components. A top down design approach based on information modeling has been proposed by D. Goense at the ISO/TC23/SC19/WG1. A critical initial step in Entity-Relationship modeling is to identify the entities involved in the system being modeled. For sprayers, part of that step is to identify the physical entities in the system. Figure 2 presents a component model in the form of a graphical description of a sprayer. Each component includes a numeric descriptor indicating the number of instances of the particular component that could occur. The components depicted are intended to serve for most configurations of sprayers that might be used. A common sprayer with a single product tank in which chemicals are mixed with a diluent can be represented by a single product tank system with no diluent tank. On the other hand an injection type sprayer may have a separate diluent tank and one or more product tanks. A single recirculation line is provided and would be used only in a common system where chemical is mixed with a diluent. The model contains multiple booms with boom section valves that can be engaged individually. A single boom sprayer could be modeled with one boom section.

Using the component model in Figure 2, sprayer process modeling and control parameters were identified. Figure 3 presents parameters in a graphic form. An attempt was made to identify those process variables that are of interest in management and control of the spraying operation. In the cases where more than one instance of the variable can occur, the variable includes a qualifying instance number. No attempt was made to differentiate between measured or status types of parameters. Figure 4 presents sprayer boom geometry information which also forms part of the sprayer management and control parameters.

Both the process monitoring and control parameters and the sprayer physical components models were used to identify sprayer physical characteristics. The characteristics identified are presented graphically in Figure 5. The sprayer physical characteristics provide the configuration of the sprayer and include maximums, minimums, and total number type of information.

Based on the parameters identified above, a more detailed description of each of the parameters must be made. The detailed list should include the parameter name, definition, and the SLOT information. Below is the detailed description for Diluent level in the form that parameters are defined in J1939. Note that the 0.4%/bit gain given a 1 byte parameter yields a range of 0% to 100%, a 2% smaller range than the expected 0% to 102%. Only 250 states are available in a byte in J1939 to describe the data range. The remaining states are error states and reserved.

Diluent fluid level - Ratio of volume of liquid to total container volume of fluid reservoir in the diluent tank.

Data Length: 1 byte

Resolution: 0.4 %/bit gain, 0 % offset

Data Range: 0 % to +100 %

Type: Measured

Appendix 1 lists definitions for each of the parameters identified in Figures 3, 4, and 5. In cases where commands appeared appropriate, both a measured value and a command parameter were included. Where parameters could have more than one instance, for example nozzle state, A count parameter and a total count parameter were included. Nozzle state, for

example, can have more than one instance and nozzle number and nozzle total number were defined.

Definition of Sprayer Messages

After parameters are defined, messages may be created to communicate the parameters. Using the J1939 style message, parameters were grouped into messages. A model of the potential communication system is helpful in determining how to group the parameters. J1939 recommends that like parameters be grouped together. The primary use of the messages defined here are to provide management information and information sharing. In both cases, the sprayer can be treated as a single entity communicating with another device, for example a data logger that might keep logs on spraying operations. The sprayer can be considered a single node. Only the first address of the block of 8 addresses allocated to an implement is well defined. This base address of the block is intended to handle any standardized requests from the implement or to respond to standardized commands that may be sent to the implement. The other nodes or addresses within the implement's block can be used in a proprietary fashion and can be used to provide information. Standardized communications to and from the implement can be considered to be primarily from the base node in the implement for the purposes of creating a message set.

To allow the communication of the sprayer configuration and characteristics, four messages were created. These include Sprayer Characteristics 1, Sprayer Characteristics 2, Agent Information Request, and the Agent Information Reply messages. Each of the replys, Sprayer Characteristics 1, Sprayer Characteristics 2, and Agent Information Reply are sent only on request and could be used by a data logger for example to determine the nature of the sprayer. Sprayer characteristics 2 required a variable length reply and would need to use the transport protocol if more than two product tanks exist. The length of the reply can be determined by the requester by first requesting Sprayer Characteristics 1. The agent information request and reply were created to allow a device to determine the information on the particular chemical agents that are placed in a product tank. Normal J1939 request messages will not allow request of information more specific than described in a parameter group number. An alternative would be to create messages to communicate agent information for each of the potential product tanks. The agent information reply is a 24 byte message and must use the transport protocol to be conveyed to the requester. The messages imply that the sprayer has knowledge of the chemicals that it contains. The sprayer could obtain this information in several ways including:

• Query of the operator through the virtual terminal.
• Through some data entry system on the sprayer (a bar code reader for example).
• Downloading the information from a user programed device.

The messages, Sprayer Tank Levels, Sprayer Flow rates, Sprayer Nozzle States, Sprayer Boom Valve States, and Sprayer Boom State were created to allow continuous monitoring of sprayer function. Transmission rate for Sprayer Flow rates, Sprayer Nozzle States, and Sprayer Boom Valve States were set to 2 seconds based on a rough estimate of the required timeliness of the information. For the same reason, Transmission rate for Sprayer Tank Levels, was set to On-request. The transmission rate for Sprayer Boom State was set to 1 second but might have to be increased to a much faster rate where a system might exercise boom height control.

The commands Sprayer Boom Command, Sprayer Boom Valve Command, and Sprayer Flow Rate Command were included to allow control of the sprayer and to allow other implements to monitor control of the sprayer. Repetition rates were set using the same strategy given above. A more extensive analysis of control systems will be necessary to better set the rates for control oriented messages. The commands and the agent information request have been set to use destination specific addressing. The potential exists that more than one sprayer may be hitched together. In this situation, these messages must be sent to the intended sprayer.

Message Set Contribution to Bus Loading

Table 3. Calculated Message Loading

Four product tanks were assumed. Forty nozzles were assumed.

A 250 Kbaud J1939 Bus was assumed. A single request to broadcast for the nozzle states message was assumed.

Table 3 shows computed message loading based on the message set that was developed. Messages that were developed with repetition rates of On-request and As-necessary were not included in the calculation. Message loading from the On-request and As-necessary messages is expected to be insignificant compared to the repetitive messages listed. The calculated message loading falls well within the 2% that would assure 16 similar implements might be connected. If repetition rates of some of the messages are shortened to allow responsive control, for example, the spray boom state and spray boom command, dramatically increased loadings can occur. Increasing both of thesemessages to 100 ms repetition rate messages would add nearly 1% to the loading. At moderate vehicle speeds, this repetition rate would result in near 1 sample per 30 cm and may not be adequate for height control. Many messages that the sprayer and other implements will need are not included in this calculation. Certainly true ground speed for example (in J1939 ground based vehicle speed ) would be present on the implement bus and could be used by the sprayer to adjust application rate.

Summary

A strategy has been presented for development of a message set that could allow J1939 to be used with agricultural implements. The paper is intended for use as a guiding example for development of message sets for agricultural implements for J1939. The message set forms the necessary addition to the applications layer in J1939 to allow J1939 to be used for a particular implement. A message set for agricultural sprayers was developed as a part of this paper and could serve as an initial document for a committee developing a message set for sprayers. Development of a useful message set requires input and review by the potential implementers of equipment using the message set. Generation of applications layer documents for implements should be a natural function within ASAE. Expertise in construction and agricultural implements exists within ASAE. Work done at ASAE in this area should form a significant part of the expertise that can be provided to the ISO TC23/SC19/WG1 in developing the network applications layer for implements for an ISO standard.

References

Bobert Bosch GmbH. 1991. CAN Specification, Version 2.0. Robert Bosch GmbH, Postfach 50, D7000 Stuttgart 1. Germany.

B. L. Luebbering, and V. R. Smith. 1993. Engine Electronics Technology. SAE Technical Paper Series, Paper No. 932404. SAE Warrendale, PA.

M. R. Stepper. 1993a. J1939 High Speed Serial Communications, The Next Generation Network for Heavy Duty Vehicles. SAE Technical Paper Series, Paper No. 931809. SAE Warrendale, PA.

M. R. Stepper. 1993b. J1939 High Speed Serial Communications, The Next Generation Network for Heavy Duty Vehicles. ASAE Paper No. 931529. ASAE St. Joseph, MI.

M. L. Stone, and M. Zachos. 1992. Straight Talk. Agricultural Engineering. Vol. 73, No. 6. ASAE. St. Joseph, MI.

M. L. Stone. 1993a. Messages to be Received By and Transmitted From the Auxiliary Valves, Three Point Hitches, and PTOs on Tractors. Construction and Agriculture Multiplex Committee (Joint ASAE 353/1 and SAE ORMTC SC19), July 13, 1993.

M. L. Stone. 1993b. Messages to be Received by Implements to Allow Control of Safety, Working, and Signal Lighting. Construction and Agriculture Multiplex Committee (Joint ASAE 353/1 and SAE ORMTC SC19), February 20, 1993.

Wang, Z., H. Lu, and M. L. Stone. 1992. A Message Priority Assignment Algorithm for CAN Based Networks. Association for Computing Machinery, 1992 Computer Science Conference, ACM. New York, NY.