Marvin L. Stone
Department of Biosystems and
Agricultural Engineering
Oklahoma State University
Standardized Class C communication networks are being developed for use in construction and agricultural equipment. Both an ISO and SAE standards are being developed. This paper attempts to summarize both standards and to discuss potential application of the standards.
Lower speed standardized and proprietary networks are being used in construction and agricultural equipment on current models (Luebbering and Smith, 1993; Young et. al. 1993). The need for higher speed standardized networks has been driven from many sources. Current networks are being used primarily for powertrain control, and to provide information to interface operator controls and dashboard displays. The capacity of the current networks does not accommodate the features and capability manufacturers would like to provide in their vehicles. Many powertrain components are being out-sourced allowing manufacturers to reduce engineering costs and provide diversity in their product lines. The out-sourcing of powertrain components creates the need for a common standardized network within the industry. Powertrain components developed for use in the Truck and Bus industry are also used in construction and agricultural vehicles. The sharing of components within both industries underlies the need to adopt a common serial communications protocol standard across the heavy equipment industries. A further need in both construction and agricultural equipment is to allow implements that are attached to the vehicle to communicate with the vehicle as well as to the operator on-board the vehicle. This capability would allow manufacturers to offer equipment that could function more efficiently and equipment systems that can be better managed.
The initiation of an ISO standard for serial communication between tractors and implements was begun in June 1991 with the formation of ISO/TC23/SC19/WG1. This working group initially focused on an interim solution based on a connector specification and non-multiplexed communication over dedicated wiring using the same connector. By February 1992, work was begun in earnest by the working group to define a multiplexed protocol that could be used across the hitch between tractors and implements. At that time, a demonstration project was underway involving a group of European manufacturers of agricultural equipment and demonstrating serial multiplex communications across the hitch. The project had generated a draft DIN standard (DIN 9684). This standard is based on CAN 1.0 (Bosch, 1991), and a 50 kbaud unshielded twisted pair physical layer.
The activity in the ISO working group generated strong interest within US agriculture and construction equipment industries. A joint SAE and ASAE (American Society of Agricultural Engineers) committee was formed in December 1991 and operated under the administration of the Equipment Manufacturers Institute to formulate a US position and to support US industry interests as a part of the ISO working group. This committee, self named the Construction and Agriculture Multiplex Committee spearheaded the effort to provide a proposal to ISO that could meet the needs of the US construction and agricultural equipment industries.
The Construction and Agriculture Multiplex Committee was aware of past and the current activity of the SAE Truck and Bus Control and Communications Subcommittee (Stone and Zachos,1993b). J1708/J1587 was being used in the Heavy Equipment Industry at the time and J1939 was being developed. The Construction and Agriculture Multiplex Committee was interested in maintaining compatibility between a standard to be used in Con-Ag Equipment and the standard that would be used in Truck and Bus systems. Many powertrain components that are used in Truck and Bus equipment are also used in Con-Ag Equipment. Some of the membership of the Truck and Bus Electronics Subcommittee are also members of the Con-Ag Multiplex Committee. J1939 compatibility, then became a necessary feature of the proposal that the Construction and Agriculture Multiplex Committee was preparing.
The Construction and Agriculture Multiplex Committee approached the Truck and Bus Electronics Subcommittee and sought extension of J1939 to support construction and agricultural equipment. The Truck and Bus Electronics Subcommittee accommodated the Construction and Agriculture Multiplex Committee and a Con-Ag Task Force was formed under the Truck and Bus Electronics Subcommittee. The needs of the construction and agriculture equipment industry have now and are yet being been built into J1939.
Table 1. Relationship between J1939 and ISO/DIS 11783 Documents.
| J1939 Component | ISO/DIS 11783 Component |
| J1939 and J1939/02 | Part 1: General Standard |
| J1939/12 | Part 2: Physical Layer |
| J1939/21 | Part 3: Data Link Layer |
| J1939/31 | Part 4: Network Layer |
| J1939/81 | Part 5: Network Management |
| J1939/72 | Part 6: Virtual Terminal Applications Layer |
| Not yet included | Part 7: Basic Messages Applications Layer |
| Not yet included | Part 8: Implement Messages Applications Layer |
| J1939/71 | Part 9: Power Train Applications Layer |
During the same period, the Con-Ag Multiplex Committee was pursuing the incorporation of J1939 compatibility into the developing ISO standard. In February 1992, CAN 2.0 with 29 bit identifiers was adopted for use in the developing ISO standard and by the summer of 1993, J1939 had been adopted as a working document by the ISO working group. Currently, ISO draft documents of the base network description, the data link, and network layers have been prepared and have the same content as the equivalent documents used in J1939. In addition, there is agreement that the network management document can be adopted by the ISO working group. The application layer documents including powertrain, basic messages for tractor to implement control, and messages for communications of process parameters for implements are not yet complete.
The physical layer being defined for use in Con-Ag systems is different from that currently defined for Truck and Bus use. J1939 defines a shielded twisted pair (J1939/11, one of the physical layer documents) for use in the vehicle for truck and bus applications. Considerable attention was dedicated to resolving the selection of a physical layer for Con-Ag use. A shielded twisted pair was regarded as un-maintainable by a majority in the construction and agricultural equipment industry. The potential for degradation of the foil shields over time was a primary factor in selection of an alternate physical layer. Vehicle life spans of 30 years are not uncommon for Con-Ag vehicles. In addition, the difficulty anticipated by service personnel in repairing a foil shielded cable was a critical problem. Bus speed was also of critical importance and a survey of the industry confirmed that a 250 kbaud bus was needed. The need for an alternative to the shielded twisted pair led to the definition of a 4 wire cabling system, an unshielded twisted quad, which is expected to meet the emission and susceptibility requirements and address the issues above. The unshielded twisted quad is in a draft form as J1939/12 and is a part of the ISO draft document.
The ability for implements to display information to an operator in the tractor and to be able to retrieve information from an operator led to the definition of a virtual terminal in the German DIN 9684 standard (Buschmeier et. al., 1993). This device provides, to multiple implements, display and keyboard resources in the tractor. The DIN 9684 virtual terminal definition has been translated and rewritten in a form appropriate for J1939 and network messages have been developed to allow the virtual terminal to exist in a J1939 system (J1939/72 draft). Currently there is considerable controversy within the con-ag industry regarding the economic feasibility of implementing the virtual terminal as currently specified. There is no controversy though over the need for a device with virtual terminal function.
J1939 includes components that are specific to construction and agricultural equipment as well as components that are specific to truck and bus applications. The overview presented below is of the necessary components of J1939 for construction and agricultural equipment applications. These same components form the working documents for ISO/DIS 11783. The table below shows the relationship between J1939 components and the current draft of ISO/DIS 11783. The J1939 document will be referred to in the discussion below. Further information may be obtained from the J1939 Recommended Practice, J1939 Drafts or in the papers by Stepper (Stepper, 1994; Stepper, 1993)
The physical layer currently planned for con-ag applications in J1939 is defined in J1939/12. This document specifies an unshielded twisted quad cable (Figure 1) with a data rate of 250 Kbaud (Baker et. al., 1994). Two of the conductors in the cable are used for signaling (CAN_H and CAN_L), and two conductors are used to provide power for active terminations at each end of the bus (CAN_BAT and CAN_GND). The CAN_BAT and CAN_GND effectively RF grounded and proved some measure of RF shielding.
Figure 3. Network Topology and Connector Usage.
Figure 1. Unshielded Twisted Quad Cable Crossection
The signaling system is a balanced 32 ma current that is held positive for a dominant and negative for recessive bits (CAN_H and CAN_L in Figure 2). A node drives active bias/terminations at the ends of the bus with these currents to create the nominal bus voltages shown in Figure 2. Electromagnetic emissions and susceptibility are critical concerns. Emissions are controlled by carefully balancing currents in the bus conductors and controlling rise times for the signals.
Termination of the bus is necessary and is accomplished with an active terminator and bias circuit which holds the bus at a recessive level unless driven dominant. The design for the physical layer places small impedance in the terminations and very large impedances in the network nodes. The resulting design minimizes the effects of having different numbers of nodes on the bus signal, allows for power bias of up to ±2 V between modules, and provides capability to operate in a single bus line mode.
Figure 2. Bus Voltage levels.
The bus design allows up to 30 nodes to be connected to any segment of the bus. The maximum length of a segment is 40 m with the stub connecting the node to the bus limited to 1 m in length.
Connector specifications are currently provided in J1939/12 and some of the locations identified. Figure 3 shows a typical topology for a con-ag system. Two busses are defined, the vehicle bus which provides for communications among powertrain and tractor associated components, and the implement bus which traverses the tractor and provides connection of implement components to the tractor. An 8 pin connector is currently defined at the rear hitch of the tractor with an optional 8 pin connector at the front of the tractor. These connectors allow provision of high current power and electronics power as well as the communications bus to implements.
The same connector may be used to extend the bus from implement to implement. This connector provides a locking mechanism, but also allows non-destructive breakaway in the even of an unintentional physical disconnection of the implement. A provision has been proposed allowing automatic termination of the bus on disconnection of the implement. Past experience has demonstrated that expecting operators to replace the terminator after removing an implement is unreliable.
A 4 pin connector is defined to allow bus extension. The same connector with different keying is planned for connection of diagnostic devices. The diagnostic connector provides power and bus lines while the bus extension connector simply passes the four wires of the twisted quad.
J1939/21 is specified as the data link layer for all current J1939 applications including construction and agriculture. A brief overview is provided here but a more comprehensive overview can be found by Stepper (1994). J1939 is based on CAN (Bosch, 1991) using 29 bit identifiers. Messages packets are composed of a 29 bit identifier and a data field of up to 8 bytes. The CAN protocol includes additional fields transmitted as a part of the packet including a data length indicator and a remote transmission request (RTR) bit. The RTR bit is used in CAN to allow request of a message. J1939 defines a request message for requesting nodes transmit a particular message and does not use RTR.
Two alternate definitions of the use of bits in the identifiers provide two protocol data units (PDU) in J1939. The two PDU formats provide a structure to direct a message to a particular node, and a structure which identifies the data content but does not direct the message. The naming of the bit fields are shown in Figure 4. J1939 defines a network system with 256 possible addresses. Of these, 253 may be assigned to devices on the network. Address 255 is the global destination address and 254 is a null address currently used in network management. All message packets include a source address of the sending node as the lowest order byte of the message identifier. Unique source addresses on the network then guarantee all messages will have unique identifiers regardless of the definition of the remaining identifier fields. CAN requires message packets have unique identifiers and arbitrates contention of messages attempting to use the bus. The message with the lowest identifier value has highest priority in bus contentions.
An independent priority field forms the first three bits of the identifier in both PDUs. This field allows the priority of messages to be set independently of the rest of the fields of the identifier and could be used to tune the performance of a particular system. The CAN protocol arbitrates access to the bus for simultaneous access in a bitwise manner starting at the highest order bits of the identifier. The priority fields are the most significant priority setting component in the identifiers in J1939 systems.
The PDU Format field in the identifier allows determination of which type of PDU is being used. If the one byte field is 240 or greater, the PDU is type 2, otherwise it is type 2. The PDU Format field has a dual purpose and is also used to identify the particular message and it's data content. The page bit and PDU Format field form a message ID number, that is a "Parameter Group Number", for PDU type 1 messages. The page bit and PDU Format field, and the Group Extension Field form a Parameter Group Number for PDU type 2 messages. This strategy allows a total of 8672 parameter groups to be defined. Construction and agricultural vehicle systems are very diverse and will require definition of many messages. The large number of possible parameter group definitions supports the diverse message set that will be needed for con-ag systems.
Figure 4. Protocol Data Formats.
J1939/21 defines a messages for acknowledgment and for requests. The acknowledgment message can be used to both acknowledge (ACK) or provide negative acknowledgment (NACK) if necessary. Some command messages are defined within the standard. These commands may require acknowledgment and use this message. In addition, when a request message is sent to a node and the node does not support the message, the node may use the NACK message.
Proprietary messages can be sent by using parameter group definitions provided in J1939/21. Both PDU types are supported with a proprietary definition. Proprietary messages must be interpreted based on the definition by the manufacturer of the device sending the message.
J1939/21 also defines a transport protocol. This protocol allows messages with data fields of 8 to 1785 bytes to be transmitted. The protocol assures that the data can be reassembled in the correct order and allows the receiving node to determine if there is missing information. Two transport protocol modes are supported, a broadcast mode and a destination specific mode. The destination specific mode includes flow control and allows the receiver to control the number of messages sent in a sequence through a handshaking sequence. This protocol is currently specified for use with the virtual terminal to allow screens to be sent from an implement and reassembled at the terminal.
The network layer, J1939/31 defines repeaters, bridges, routers and gateways. No provisions are included for redundant bridges and the associated spanning tree algorithms or equivalent. Simple branched networks without loops are planned.
Two applications of bridges are planned in con-ag systems. A bridge is specified for connection of the vehicle bus and the implement bus. In addition, bridges may be used to place controllers on an implement on a subnet. Both types are shown in Figure 3. The vehicle to implement bus bridge provides both electrical and message isolation of the vehicle bus from the implement bus.
Table 2. Components that are defined in a J1939 message.
| Element | Range/Options |
| Name and Definition | |
| Length | 0 to 1785 bytes |
| Parameters | Name, position, and length in data field |
| Protocol Data Unit (PDU) Type | PDU 1 (Destination Specific) or
PDU 2 (Extended Parameter Group) |
| Repetition Rate | currently 10 ms to 10 s or
On request or Per User Requirements |
| 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 |
Manufacturers of tractors are particularly interested in filtering messages that may be sent to the tractor from implements. J1939/31 defines filtering capability for bridges. Message filtering cannot be as simple with J1939 as it would be with ethernet or other protocols where every packet has a source address and a destination address. Transparent bridging algorithms (Naugle, 1994) can be used with PDU type 1 messages but messages that have no destination address must be filtered based on their Parameter Group Number, which identifies their data content. J1939/31 defines a filter database contained in the bridge that may be enabled or disabled for particular Parameter Group Numbers. A device on the network can enable a particular message to be passed by sending a command message to the bridge. In con-ag applications, most messages on the vehicle bus except those which must be passed will be filtered. Devices on implements may attempt to retrieve messages that are being filtered by enabling the bridge to pass the particular message. Bus traffic load on the vehicle bus currently comprises about 30% of capacity. Filtering in the bridge is necessary to prevent implement traffic load from adversely affecting the tractor.
Table 3. Components that are defined in a J1939 parameters.
| Element | Range/Options |
| Name and Definition | |
| Length | 1,2 bits, 1,2,or 4 bytes, or ASCII string length |
| Type | Measured or Status |
| SLOT (Scaling, Length, Offset, and Transfer function) | Pre-defined SLOTS are provided |
A gateway is defined in the draft base document for construction and agricultural applications of J1939 (J1939/02) as shown in Figure 3. This gateway is provided as a means of transferring information to and from the tractor/implement system from a management computer. A typical use for the information transferred through this gateway would be to collect process information from an implement during field operations and to allow that information to be summarized by software on a producers home computer. A standard data format is (ISO/DIS 11787) defined for providing the information from this gateway to the management computer. The translation of the data into this format may be done within the management computer. The supplier of the gateway would need to be responsible for specifying or providing the software and hardware to allow the data transfer.
The applications layers in J1939 define messages that may be sent on the bus. Three applications layer documents currently exist, J1939/71 which should be viewed as the base application layer document, J1939/72, a virtual terminal message set, and J1939/73, a diagnostics message set. J1939/71 defines the general structure of messages and defines the data encoding in the message. Table 2 shows the components of the message that must be defined when creating a message. A parameter Group Number is assigned to each defined message.
Parameters in J1939 may be logical, 1,2 or 4 byte
scaled binary numeric, or ASCII. Logical parameters may be simply
a one or zero but the recommended parameter would contain two
bits allowing the logic state, errors, or availability to be indicated.
The error or availability state indication is also included in
the binary numeric and ASCII parameter encoding. This feature
allows the indication of errors or availability of single parameters
within a message.
An example of a message, Vehicle Position, currently defined in J1939/71 is shown in Figure 5. The Latitude parameter definition is also shown in Figure 6. A complete message definition includes complete specification of parameters and of the message.
Transmission repetition rate: 5 sec
Data length: 8 bytes
Data page: 0
PDU format: 254
PDU specific: 243
Default priority: 6
Parameter group number: 65,267(00FEF316)
Byte:
1-4 Latitude 3.2.5.83
5-8 Longitude 3.2.5.84
This message is designed to be sent by a task controller to an implement or from an implement to a data logging system and provides a capability to communicate process variables or set-points. The message allows a request for the variable as well as the variable to be transmitted.
Transmission repetition rate: Per User Requirements
Data length: 8 bytes
Data content identifier: not defined
Byte 1
Bits 8,7: Value/Setpoint
Bits 6-4: Modifier
Bit 3 NA
Bits 2,1: Data type
Byte 2: Implement position
Bytes 3,4: Process variable identifier
Bytes 5-8: Process variable
Data Length: 4 bytes
Resolution: 10-7 degree/bit gain, -210 degree offset
Data Range: -210 degrees (SOUTH) to + 211.108 122 degrees (NORTH)
Type: Measured
Messages currently defined in J1939 are packed parameter messages. In the example shown above, two related parameters Latitude and Longitude are packed in the Vehicle Position message. The developing ISO/DIS 11783 includes two additional applications layer documents, Basic Messages, and Implement Messages. The Basic Messages document will contain messages that are primarily intended for communications between implements and components on the vehicle bus of the tractor. These messages are being developed as packed parameter messages in the style of current J1939 messages. There is some controversy remaining over the implement messages. These messages will primarily support communication of process setpoints from implement control units on-board the tractor but on the implement bus and the implement. In addition, this message set will support communication of process operating points or critical control parameters forward to data logging devices. The current controversy concerns whether packed parameters are appropriate for this communication process. Two strategies have been presented regarding implement messages. A packed parameter strategy was presented by Stone and Zachos (1993a). This strategy uses the J1939 transport protocol heavily and demonstrates for an agricultural sprayer that a packed parameter message set can be constructed. The packed parameter strategy works best where the sending and receiving nodes for messages can be well identified. The paper assumes that some device on the tractor will be the primary receiver and transmitter of process control information and an implement controllers will normally be associated with a set of parameters.
The alternative strategy has been presented by the DIN group at the ISO/TC23/SC19/WG1. This strategy places several parameters in a message but extends the number of parameters that might be communicated to 64535 by adding a Process Variable Identifier as a parameter in the message. In addition, this strategy implements a capability to send or request setpoints or process variables using the Value/Setpoint parameter. A modifier parameter is included which may be used to specify default, current, average, maximum, minimum, etc. qualifiers for requested or setpoint values. An implement position is associated with every parameter. Implements typically are made up of many sections and in these cases a position parameter must be associated in some way with the process variable. The original proposal provided only for integer or floating point representations of the variables. An agreement was obtained that floating point was not necessary at this point and that scaled binary representations are acceptable. The Data Type field specifies the numeric representation of the data.
Network management which normally is found distributed among several layers of the ISO OSI model is placed in the Network Management document (J1939/81) in J1939. This organization places emphasis on network management, though special care must be taken in viewing layers of J1939 as modular and interchangeable with new layers. In particular, the Data Link and Network Layers of the document are closely interrelated to the Network Management document.
J1939/81 focuses on four areas:
1. Address management
2. Naming of nodes
3. Reporting network errors including: Duplicate names, addresses, and illegal address use.
4. Request and response to Parameter Group Numbers sourced or acted upon
Address management is necessary in J1939 to allow some nodes to obtain a proper address, that is, to allow dynamic addressing of some nodes. Static and dynamic subnetworks have been defined in J1939. In static networks, the node address of a module is programmed at vehicle configuration. This process is impractical for devices that must be connected and disconnected from the vehicle dynamically, for example, trailers for on-highway equipment, and implements for construction and agricultural equipment. Setting addresses manually through operator intervention is not deemed acceptable by either of the industries involved in J1939.
J1939/81 implements a node naming strategy. Node names are a 32 bit number made up of fields identifying the industry group (General, Truck and Bus, Construction and Agriculture, etc.), the device identification (engine, brakes, field sprayer), device instance (e.g. instance of engine), and controller component instance (e.g. instance of controller belonging to the instance of engine). The name assigned each component in the vehicle must be unique and allows disassociation of predefined addresses and devices. J1939 includes preferred addresses and these addresses are planned for use by static devices and dynamic devices may initially attempt to claim appropriate preferred addresses.
Dynamic address assignment is done on a peer to peer basis in J1939. Dynamic devices must issue an Address Claim request from the null address on initialization and based on the responses, may claim an address above 128 that is not currently used. Devices must recognize their communications partners through the name provided during the response to an address claim request. This then requires each device retain an address and name table. The potential exists for devices to attempt to claim the same address. This potential is minimized through detection of the duplicate claims and randomization in the timing of claims.
J1939/81 provides capability for reporting network error messages and requires all dynamic devices detect duplicate address events and be able to report inability to claim addresses. In addition, a provision is made in the document to request and respond to requests for parameter group numbers sourced or acted on. This feature allows bridging devices to determine all parameter groups that must be passed as well as providing a diagnostic tool or data logger to determine the active message set.
The requirement of unique names in the network causes some difficulty with agricultural implements and with on-highway trailers. These devices may normally be assigned the first instance during configuration at manufacture. A process has been proposed for construction and agricultural equipment and a different process for on-highway trailers for automatic determination of instance for these devices. The process for construction and agricultural equipment is described below. The process for on-highway trailers is different and the reader may obtain the latest proposals from the Network Management Task Force of the J1939 committees.
The process defined for determination of instance in agricultural and construction equipment relies on sequential connection of implements during the configuration of a combination of machines. An example to assist the description might be configuration of three drills. It is common to hitch several drills side by side to form a very wide drill. Each drill may be programmed at manufacture for the first instance. If the drill has several controllers, each controller would have the first instance of drill and would have sequential controller component instances with the main controller being the first controller component instance. During configuration, the drill intended to be the first instance is connected to a live bus and will be powered and initialize. At this point, the drill (the first controller component instance) will send an Address Request and check to determine if the first instance of drill exists. Since it is the only drill connected, it will not find a first instance and will select that instance. The drill then will send an Address Claim which allows it to secure an address and announces it's name. The drill must also announce it's serial number (Component ID message) which allows the other component controllers to identify their associated controller and to determine their instance. At this point the other component controllers can proceed with dynamic address claims. The second drill may then be connected and will follow the same sequence but since the first instance of drill exists, the second drill must assume the second instance. The process may then be repeated with additional drills. The manufacturer must provide a mechanism to reset the device instance to allow the equipment to be re-configured. Once the implement device instances are set they should be retained for subsequent initializations until reset. This process is only necessary where multiple instances of the same implement device type are to be configured. For typical operators, changing the arrangement or configuration of multiple implements ganged into a single system would be rare. The change normally requires significant mechanical disassembly and reassembly and the process of sequential connection on configuration is practical.
Definition of a diagnostics application layer for J1939 has begun. A draft document, J1939/73 exists and utilizes features from J2012 and J1587. The features in the current draft are described below but have not been rigorously discussed by the Diagnostics Task Force of the J1939 committees. The features are described below.
Access to diagnostic functions is controlled with a security mechanism that provides manufacturers with controlled access and is expected to meet any legislated anti-tampering requirements. The process to allow access to change controller settings from a service tool standpoint, consists of sending a request to access, receiving a seed, sending an appropriate key, and receiving an appropriate response.
A single PDU type 1 message is planned for diagnostics. This message allows directed as well as broadcast information. The different functions or modes that are needed are encoded as the first byte in the data field of the message. The remaining 7 bytes are then used for the data required by the mode byte. The 256 mode byte values are defined as requests or responses depending on the state of bit 6 of the byte, with values $00 through $3F and $80 through $BF being requests and the remaining values responses. The initial draft of the document defines capabilities including request of diagnostic data, request of freeze frame data, request of diagnostic trouble codes, Selected clear or reset of diagnostic information, clear or reset of freeze frame data and clear or reset of all diagnostic information.
Figure 8. On-screen features of the virtual terminal.
A virtual terminal in the context of construction and agricultural vehicles is an operator interface device. The terminal is defined to provide an operator interface resource to implements. Multiple implements may gain access to the terminal simultaneously and the terminal may display one or more screens, as formatted by implements, to the operator. Virtual terminals may also provide keyboard or other devices to retrieve input from the operator. A draft of a virtual terminal definition has been developed. This document, J1939/72, is based on a translation of the DIN 9684 virtual terminal definition. J1939/72 is placed in the format of the other J1939 documents and defines two messages for virtual terminal interactions, a message to the terminal and a message from the terminal. The various functions of the terminal message set are coded into the first byte of the two messages, allowing 256 from messages and 256 to messages. Loading of screens or other functions requiring transfer of many messages are defined to use the transport layer of J1939.
Figure 8 illustrates the screen of an example virtual terminal and identifies features of the terminal. The document defines capabilities to download informational screens, hierarchical menus, and alarm screens to the terminal. A special key on the example terminal could be used to page between screens of implements. Functions are defined to allow numeric and alphanumeric information to be retrieved from the operator. Currently, a required feature is that it allow alphanumeric data entry. Function keys are required on the terminal. These may be implemented as the terminal builder requires but during configuration of the terminal, descriptive text is sent for the function keys available and must be displayed in association with the function key.
Many optional features are defined for the terminal including both the ability to send vector graphic drawing commands as well as send bitmaps. The limited bandwidth of the network prevents complex drawing or large bitmap information from being transferred. Text input and output are required features.
A typical process in using the terminal from an implement point of view would be to send screens, menus, and alarm screens to the terminal on initialization. During operation, the appropriate screens would be selected by the implement based on function key codes returned when the operator selects menu items. Alarms would be sent as necessary. On disappearance of the implement, the terminal would release the resources claimed by the implement.
J1939 is expected to be applied in many situations in construction and agricultural systems. An example is selected here to illustrate tractor and implement interaction in an agricultural application using the emerging technology of precision farming. Figure 9 illustrates the example system.
The tractor uses the vehicle bus in a manner similar to on-highway applications and uses the message set currently specified in J1939/71. The implement, a fertilizer applicator, is used to apply fertilizers and varies application rate based on ground speed of the vehicle. The main applicator controller can receive setpoints in the form of application rate per unit of area covered and adjust flow within the system to achieve the proper coverage. To do this the implement requires groundspeed which is passed from the vehicle bus to the implement bus by the bridge (width of the applicator must be known by the Main Applicator Controller). The boom controller allows sections of the boom (spreading mechanism) to be turned ON or OFF based on operator commands. In addition, the boom controller may be used to fold the boom for transport.
Figure 9. Example system showing a precision farming
application.
The Task Controller, Map Information device, and Management Computer Gateway device receives instructions from the management computer through the gateway path. The instructions consist of the application rate per unit area for sections of the field with an associated latitude and longitude. The Task Controller can send setpoints to the Fertilizer Applicator based on current latitude and longitude. The device can also log the current application rate and the latitude and latitude for later download through the gateway to the management computer. The Task Controller communicates with the Virtual Terminal to allow an operator interface and behaves as an implement in this manner. The Task Controller also retrieves latitude and longitude information from the GPS unit mounted on the implement bus. The implement (Main Applicator Controller) uses the virtual terminal for necessary communications with the operator.
This combined system allows the operator to specify appropriate application rates in the field with respect to map positions. Equipment is in production with the features described above. The current equipment is application specific and does not use standardized communications. Research is underway to evaluate the benefits of precision farming technology (Peterson et. al., 1993). The outcome appears to be favorable and manufacturers are preparing to support the technology. The application described above would result in a light bus loading. The implement/task controller interaction would consist of setpoint commands and returned measured values. These would probably occur at less than once per second. GPS information would be broadcast at similar rates. Virtual terminal interactions would be light once screens are downloaded.
Other potential applications would tax the bus bandwidth heavily. Coordination of the movements of implements with the tractor require control loops across the hitch of the tractor. The tractor can provides hitch height control which could be controlled from an implement. In the case where planting depth is controlled from the tractor, and a sensor on the implement can be used to detect depth, the implement controller can be used to command the hitch on the tractor. This type of control system today would require remote powered elements on the implement from the tractor with power control elements in the implement. Where the tractor is used with all implements, it makes sense to place expensive control elements on the tractor. In the height control application. the existence of the communications bus allows cost effective height control in the implement. This type of system is not common on current implement designs. The height control system would require height commands and hitch status commands at repetition rates of 10 ms. These two messages would consume 10% of the bandwidth of the implement bus and don't consider additional implements that might exist at the same time. In planting systems, it is common to have fertilizer application, planting, and chemical application occurring simultaneously. With a 30% maximum bandwidth target, careful integration will be necessary to avoid overloading the bus.
A description of both the ISO/DIS 11783 and SAE J1939
has been given above and presented from the viewpoint of application
in construction and agricultural equipment. The last part of the
paper provides an educated speculation on the potential use of
the complete network but focuses on the implement portion of the
system. The vehicle bus portion of the system will be used very
similarly to on-highway applications and better reviews can be
found elsewhere for this application. Parts of J1939 have been
balloted and will soon be available from SAE. The ISO/DIS 11783
drafts are being prepared for ballot with a target date of approval
in February 1995.
Baker, K., D. Brandon, and C. W. Formwalt. 1994. CAN Physical Layer for Off-road Equipment. ASAE Paper No. 941078. Presented at the ASAE International Summer Meeting. Kansas City Mo. ASAE, St. Joseph, MI.
Robert Bosch GmbH. 1991. CAN Specification, Version 2.0. Robert Bosch GmbH, Postfach 50, D7000 Stuttgart 1. Germany.
Buschmeier, R., H. Wei, and J. A. Hald. 1993. Operator Interface for a Standardized Open MAB System. ASAE Paper No. 931623. Presented at the ASAE International Winter Meeting. Chicago, IL. ASAE, St. Joseph, MI.
Luebbering, B. L. and V. R. Smith. 1993. Engine Electronics Technology. SAE Technical Paper Series, Paper No. 932404. SAE Warrendale, PA.
Naugle, M. 1994. Network Protocol Handbook. McGraw Hill Inc. New York. ISBN 0-07-046461-8
Peterson, C. L., Bin He, G. J Shropshire, and K. B. Fisher. 1993. A spatially variable management system for the application of fertilizer for the production of winter wheat in the Palouse. SAE Paper No. 932423. 1993 International Off-Highway & Powerplant Congress & Exposition. Milwaukee, WI. SAE, Warrendale, PA.
Stepper, M. R. 1993. J1939 High Speed Serial Communications, The Next Generation Network for Heavy Duty Vehicles. SAE Technical Paper Series, Paper No. 931809. 1993 SAE Future Transportation Technology Conference, San Antonio, TX. SAE Warrendale, PA.
Stone, M. L. and M. Zachos. 1993a. Application of J1939 Networks in Agricultural Equipment. ASAE Paper No. 931530. Presented at the ASAE International Winter Meeting. Chicago, IL. ASAE, St. Joseph, MI.
Stone, M. L. and M. Zachos. 1993b. Class C Communications Protocol Proposal for Off-Road Vehicles. SAE Paper No. 930007. SAE International Congress and Exposition. SAE Warrendale, PA.
Young, S. C., D. G. Sokol, and R. P. Strosser. 1993.
Utilization of CAN Technology in a Distributed Control System.
ASAE Paper No. 931535. Presented at the ASAE International Winter
Meeting. Chicago, IL. ASAE, St. Joseph, MI.