MOOK project 'Spider', CAN monitor for the TINI

Scheduled: 2000-04-01 to 2000-10-31
Organization: WUR, agricultural engineering and physics
Jaap van Bergeijk

1. Introduction

Agricultural implements, especially when used in precision agriculture reserach, are equipped with a number of sensors to monitor operating conditions and a control system to realize field operation specifications. In case of a field experiment, the lack of an online connection between researcher and implement limits the intervention possibilities of the researcher to control the experiment. Currently, the information flow and experiment setup is based on the existence of a boardcomputer on the implement itself, which is operated by the driver. The consequences are that for instance when a variable rate fertilizer experiment is carried out, the application rates have to be transferred to the implement prior to the field operation and evaluation of the actually applied amount is only possible when the implement has finished its operation. To be able to control field experiments more directly, a link between the implement and the computer system of the researcher is necessary.
The objective of this project is to develop a prototype system that is able to establish an on-line connection between agricultural equipment and the TCP/IP based network, as commonly used on the ethernet of research stations. Two development phases are distinguished. 1) A connection between a stationary model of the implement control system, and 2) The implementation of the wireless access to the implement during field operation. The scope of this project is limited to development phase 1.

2. Materials & method

On the implements, a Controller Area Network (CAN bus) connects boardcomputer, sensors, actuators and control systems. The protocol on this network is standardised according to the ISO 11783 proposals to ensure that implements from different manufacturers can operate on the same CAN bus. In this project, two different implements will be used. The first one is a site specific fertilizer applicator capable to execute variable rate fertilizer experiments and the second one is a sugar beet harvestor fitted with a yield mapping system.
A stationary test model of the fertilizer spreader is used in development phase 1. This stationary model uses a drawing tablet to simulate a Global Positioning System (GPS) receiver. Furthermore, a task controller is programmed to retrieve the application rate for the actual GPS position from a geographic information system (GIS) and sends this rate over the CAN bus to the variable rate fertilizer controller. The variable rate fertilizer controller is part of the fertilizer spreader and sets the fertilizer flow control valve to realize the required application rate (Fig. 1).
The stationary model for the sugar beet harvester consists of the same components as the final mobile version (Fig. 2). The only difference is that the components are linked to a CAN bus in a laboratory and that the signals of some of the sensors, connected to the components, have to be simulated to test conditions that occur during field operation.
For the bridge between TCP/IP ethernet and the CAN bus on the implements a TINItm micro-controller board is used. This board contains a Dallas Semiconductor 80C390 microcontroller and an ethernet interface. One of the pheripheral function blocks of the 80C390 is a dual CAN bus controller and this feature makes the TINI board a logical choice for a pilot implementation. Included with the TINI is a real time operating system and a JAVA Virtual Machine. The support of network protocols in the JAVA language is good and most of the java.net classes are also supported by the TINI JVM implementation. For the hardware connection between the TINI simm module and the CAN bus, a socket board with a suitable CAN physical layer driver is needed. The 'TILT' socket board from the company Systronix was used to mount the TINI between an ISO-11783 compatible CAN bus and a TCP/IP network.

Figure 1. Stationary model of site specific fertilizer spreader connected to internet

The unified modeling language (UML) is used for software documentation. The 1998 version of the Rational Rose UML case tool supports JAVA data types and class libraries. Due to the fact that code generation for JAVA was not completely implemented in this version of the case tool, the diagrams are for documentation purposes only.
The JAVA source files for the pilot project are compiled against Java Development Kit version 1.2.2. The JBuilder programming environment is augmented with TiniTools, a freeware utility that automates downloading and execution of new Java classes to the TINI board.

Figure 2. Components of sugar beet yield mapping system

3. Results

3.1 CAN bus bit timing

The first preliminary tests to connect the TINI to the CAN bus showed that the CAN bus bit timing requirements of the ISO-11783 specification could not be met by the standard version of the TINI. The only way to solve this problem was to change the crystal of the microcontroller oscillator. Possible alternatives were to use a 16, 18 or 20 MHz crystal. Both the 16 and 20 MHz crystals were tested and finally the oscillator frequency was increased from the standard value of18.432 MHz to the adapted value of 20 MHz to get the correct bit timing values on the CAN bus. Despite an increased heat dissipation, the TINI operated well at this frequency and further results are obtained with this modified TINI. Because a modification of the oscillator affects several other function blocks of the microcontroller, the RS232 serial connection standard baudrates could not be used simultaneous with the ISO-11783 CAN bus bit timing specification.

3.2 Pilot application

The common denominator of both experimental implements is the CAN-bus. For the pilot implementation of a connection between each implement and a TCP/IP network it is therefore desirable to have a generic or reusable design for the module that connects the CAN bus to the TCP/IP network. Consequently, any implement specific monitoring or control functions must not be implemented on the TINI hardware itself but should be implemented at the client side i.e. the computer platform of the researcher. Although there are also some drawbacks to this approach, a pilot implementation of a Can Monitor for the TINI was made to test the performance of the TINI as a bridge between the CAN bus and an Ethernet connection.

3.2.1 Can Monitor Server

The server part of the pilot application runs on the TINI hardware. The server handles connections from clients on the TCP/IP network and processes requests for information regarding status of the CAN bus or requests to route CAN data frames between client application and the CAN bus. To protect theTINI against processing overload, the number of simultaneous clients connected to the server can be limited. Also, a form of authentication is used to identify the client and to limit routing of CAN frames to a client that connects to the server. Fig. 3 depicts the static UML class diagram of the server classes.

Figure 3. UML class diagram of the Can Monitor server application

The CanMonitorServer class contains the 'main' application entry point. This class initializes the singleton class CanBusInterface and waits for a client to connect over a TCP/IP connection. When a client connects, a new instance of the CanMonitorServer is started and a CanStatusClient and CanFramesConnection are instantiated. The client can start or stop forwarding of CAN frames over the TCP/IP connection by commands issued to the CanStatusClient. When CAN frame forwarding is enabled, the instances of CanFramesConnection and CanFramesClient are responsible for respectively transmission of CAN frames to the client or reception of CAN frames from the client. A CAN frame is transmitted in serialized form through a data stream (java.io classes DataInputStream and DataOutputStream are supported on the TINI java virtual machine implementation). The classes CanBus and CanFrame in fig. 3 are part of the TINI comm package supplied by Dallas Semiconductors. The java code of the Can Monitor server classes is listed in appendix A. Figure 4 shows the system log of a session in which a client connects two times to the Can Monitor server application on the TINI.

Figure 4. Client connection to the CanMonitor server application on the TINI

When the client connects, the number of current connections is checked. Figure 4, line 3 shows this is connecting client number 1. At this point the client connection is accepted, a new thread of control is started and a CAN frames connection is instantiated. As soon as the client requests to forward CAN frames, both a frames client thread (line 6) and a frames connection thread (line 7) are started for reception and transmission of CAN frames over the TCP/IP connection. The current number of CAN frames received thus far by the CanBusInterface from the CAN bus is also shown on this line (37009 CAN frames). From this moment on all CAN frames on the CAN bus are forwarded to the client and the client may transmit CAN frames to the CAN bus. When the client wants to stop CAN frame forwarding, a close frames connection command is issued on the status connection causing the Can Monitor server to close the CAN frames connection (lines 8, 9 and 10). At last, the client disconnects completely, which is detected by the server though a status send exception (line 11). The server then closes the session by stopping the client status thread of control (lines 12 and 13).

From the TCP/IP address information of the status socket the information can be retrieved that this test was executed on a local ethernet section (192.168.*.*) between a personal computer and the TINI board connected to a stationary CAN bus segment.

The reason for creation of separate threads of control for the reception and for the transmission of status and CAN frame connections is that each receiving thread is blocked while waiting for data for the client.

3.2.2 Can Monitor Client

The Can Monitor client is a graphical java application running on a personal computer with classes that maintain status and frame connections with the server application on the TINI. A screen dump of this application is depicted in figure 5.

Figure 5. Screen dump of Can Monitor graphical client.

The right pane of the Can Monitor client application shows a log of the CAN frames received from the server. In this example, the CAN frames were transmitted by a GPS receiver and contain position and GPS status information. Five different parameter groups can be distinguished in this CAN frame log:

  • ExtID 18FEE61C: GPS based Time and Date (ISO-11783 parameter group)
  • ExtID 18FFF31C: Proprietary GPS status information
  • ExtID 18FEF31C: GPS based Latitude and Longitude (SAE J1939 parameter group)
  • ExtID 18FEE81C: GPS based Speed, Heading and Altitude (SAE J1939 parameter group)
  • ExtID 18EEFF1C: Name of Electronic Control Unit (ISO-11783 parameter group)

    • The information of each parameter group is encoded in eight bytes, the maximum length of a CAN frame. In this example log, the GPS receiver sends updated information (four CAN frames) once per second. The Name of the Electronic Control Unit was requested by the Can Monitor Client. A request consists of sending one CAN frame from the client to the server on the TINI and results in a response from the CAN bus participant which is transmitted back to the Can Monitor client. A specialized client for a specific implement or module on the CAN bus could further process these CAN frames and present the data in a more user friendly format, for example as a graphical line of a parameter against a time axis or as an X,Y plot for the GPS position measurements. The classes of the Can Monitor client responsible for the connection to the Can Monitor server are listed in Appendix B.

    3.3 Connection to a stationary CAN bus

    This pilot implementation demonstrates the capability to connect over a TCP/IP network to the CAN bus of a stationary implement. Analysis of the forwarded CAN frames as depicted in figure 5 showed that data is correctly transmitted between client and server. Expansion of the CAN bus with other components of the sugar beet harvester and fertilizer spreader was possible. For example decoding of the CAN frame that contains the name of the CAN bus participant yields:

    The extended identifier of the CAN frame ExtID is 18EEFF1C and consists of four bytes:

  • 18h : priority of the CAN frame: 6,
  • EEh: parameter group number is 238 which stands for 'Address Claimed',
  • FFh: parameter specific field which stands for 'Globally Addressed',
  • 1Ch: source address of component: 28 is the preferred address of a navigation module.

    • The data field of this CAN frame is 8 bytes long, the decoded information is:

  • Identity Number: 0F470Ch = 1001228 (serial number of CAN module)
  • Manufacturer Code: 7FEh = 2046
  • ECU Instance: 0h = First instance
  • Function Instance: 0h = First function instance
  • Function: 17h = Vehicle Navigation
  • Device Class: 0h = Non specific system
  • Device Class Instance: 0h = First instance of device class
  • Industry Group: 2h = Agricultural and Forestry equipment
  • Self Configurable: 1h = True, this CAN module can dynamically obtain a source address

    • These name settings correspond to the information stored in non-volatile memory of the GPS receiver connected to the stationary CAN bus.

    4. Discussion & Conclusions

    The implementation of a Can Monitor client / server application for the TINI was one method to make agricultural implement control accessible through internet. For specific applications like tracking of implement positions or logging of application rates more dedicated applications can be created. The pilot implementation did not make use of applets to enable a webbrowser to access the agricultural implement. However, the server part of the CanMonitor can be accessed by a client applet in a similar way as the Can Monitor java application connects to the server. In that case the TINI is used both as a webserver and an application server. In order to reduce the processing requirements on the (lightweight) TINI platform the current solution of a Can Monitor server application was chosen.

    Processing power of the TINI is still a limiting factor in this pilot implementation. At high data traffic rates on the CAN bus, the can monitor client is not capable to show all received CAN frames in the output log. A possible alternative in that case is to use a specialized client that just logs CAN frames or applies a filter to just show CAN frames of a specific CAN component or parameter group. Another option to reduce traffic over the TCP/IP connection is to enable CAN frame filtering in the server application on the TINI. A client can then request the server to only forward CAN frames that match a specific pattern in the CAN frame identifier.

    Issues only partly addressed in this pilot are safety concerns and reliability of the data transfer of TCP/IP. Forwarding CAN frames over a TCP/IP to the CAN bus offers the possibility that external process influences implement operation. Of course this was intended as stated in the introduction but in the case of a connection to a vehicle guidance controller or to a chemical applicator implement, erroneous data can have very unwanted effects. For this reason, in the pilot application a client initially just opens a status connection to monitor status of the CAN bus and does not allow forwarding to CAN frames. After a form of authentication the server application connects back to the client to open a different CAN frames connection. This method should be expanded in a real application to also monitor integrity of the CAN frames send over the TCP/IP connection.

    The implementation of the Can Monitor server application showed that the TINI hardware is accompanied by a good Java Virtual Machine. Comparison of the client classes running on the TINI with the server classes that are executed on a personal computer reveals that most of the java.net classes behave similar on different computer platforms. The result is that the objective of the java language to create portable software in this case succeeded. The drawback, a slower execution of java byte code on the TINI hardware when compared to a cross compiled application specific for the 80C390 controller could not be verified but might be interesting to explore.

    APPENDIX A.

    Download CanMonitor TINI Server sources as JBuilder project (20 KB)

    APPENDIX B.

    Download CanMonitor Client sources as JBuilder project (56 KB)

    last updated: 2001-01-15