ISOBUS

ISOBUS is the common name for agricultural data bus applications that conform to the ISO 11783 standard . This standard defines firstly the physical properties such as plugs and cables, secondly the type of participants and thirdly the data formats and interfaces of the network. The basis is the SAE J1939 and NMEA-2000 protocols as well as the older DIN 9684 standard.

Requirements for modern agricultural technology

ISOBUS is related to newer concepts for agriculture, forestry and municipal management. The goals are precision farming and “transparent production”.

In order to determine the necessary dosages for fertilizers and pesticides, it should be taken into account which conditions are found on the respective field. For example, more pesticides should be distributed on a more weed field than on others (see Precision Farming ). It should also be recorded which measures were taken during the cultivation of the individual fields, so that it is possible to understand the conditions under which the plants grew (transparent production). These modern forms of agricultural engineering require that devices are used that can continuously exchange data with one another. ISOBUS has now become the worldwide standard for this exchange and has replaced various manufacturer-specific solutions and its predecessor LBS.

There is also a desire to automate agricultural operations. The devices should do their work in the field without human intervention. Such a robot-like behavior will only exist if it can be programmed beforehand which measures are to be carried out in each case. This also requires smooth communication between the devices.

By using ISOBUS-compatible devices, farmers can gain a better overview on the tractor. Attachments that are controlled from the tractor via a terminal have been in use for a long time. Until now, however, there was a separate terminal for each device. With ISOBUS it is possible to control attachments of different types (and also different manufacturers) via the same terminal.

In the meantime, farmers can also georeferenced the PC on the farm to determine how much fertilizer and pesticides should be applied. These application maps or dose specifications are then transferred to a tractor control unit and passed on from there to the attachments. Likewise, sensors on the attachments can determine data on soil conditions, weed quantities and other things and pass this data on to the tractor control unit so that it is georeferenced and temporarily stored there and transferred to the farm PC or the cloud .

The forerunner: Agricultural BUS System (LBS)

The agricultural BUS system was developed at the Technical University of Munich under the direction of Hermann Auernhammer .

It was based on the OSI reference model . However, only layers 1, 2 and 7 had to be taken into account. The decision for the CAN bus was made early on . This covers a large part of layers 1 and 2.

Although the LBS was standardized by the DIN (DIN 9684), it could not prevail. For a long time there was great skepticism among manufacturers of agricultural machinery when it came to the question of whether they would be able to agree on common standards. At the same time it became apparent that the choice of a CAN bus with an 11-bit identifier and the significantly smaller address space in contrast to a 29-bit identifier would have less of an impact on the participants than on the possible number of different PGNs ( Parameter Group Number) and a data rate of 125 kBit / s a little expandable system was created.

However, at that time there were already highly automated applications for research purposes that were more functional than anything that was commercially available until about mid-2008.

Creation and organization of ISOBUS

Orga

Despite these setbacks, the basic problem remained. In the meantime, the manufacturers of agricultural machinery had also recognized that a bus system would be unavoidable. Under these conditions an international merger took place. Many of the basic ideas of the LBS were retained. However, the concept was designed to be more efficient and expandable. The ISOBUS developed from the LBS. This is meanwhile supported by all important agricultural machinery manufacturers, both the manufacturers of tractors and the manufacturers of attachments. The standard is managed by the AEM (NAIITF) in North America and the VDMA in Germany. A task force for South America is planned.

WG stands for the individual working groups that develop individual aspects of the standard and develop new sections. Both associations meet regularly. There is also an exchange between the two groups via the Steering Committee. In the meantime, the development has clearly shifted from universities to industry. In the context of the dying of the agricultural engineering universities, this topic is only treated or actively developed by very few universities and technical colleges.

Timeline

1970 First use of electronic displays in tractors
1975 First electronic controls in tractors
1991 Start of standardization of the LBS in Germany DIN9684
1991 Start of standardization in the USA and Canada ISO11783
1994 First geo-based functionalities
1996 Demonstration of the interoperability of LBS devices
2001 Decision to transfer the LBS to the ISOBUS
2001 Foundation of the IGI
2002 NAIITF founded
2004 Foundation of FTI in Brazil
2008 Foundation of AEF to replace IGI, NAIITF, FTI

AEF

The AEF (Agricultural Industry Electronics Foundation) is an association of companies that are active in the field of electrics and electronics in agriculture. One of the main focuses is the further development of the ISOBUS. In addition to administrative tasks for coordination and coordination with the standardization groups, there are also numerous working groups. B. take care of high speed ISOBUS, wireless infield communication, compatibility tests, TIM and interfaces to FMIS. The working groups are international across manufacturers. The aim is to transfer completed projects into the standard. Another field of activity is to promote the spread of ISOBUS through marketing activities.

The AEF publishes the compatibility of the tested devices in the AEF-ISOBUS-DATABASE.

ISOBUS hardware

In a fully developed ISOBUS system, a number of devices are used, all of which function like small computers. In some cases, devices such as the virtual terminal, task controller and file server are combined in one device and even on one CPU. It is also not uncommon for several logical implement controls to be combined on one CPU, e.g. B. in a field sprayer in which each section has its own logical ECU.

ISOBUS connector

ISOBUS Breakaway Plug (IBBP) on the implement side

With the introduction, an agreement was reached on a uniform plug for connecting attachments. This not only provides the data lines, but also connections from which electrical power can be drawn. It is also provided that a circuit is included which, if necessary, actively terminates the CANBUS. This is necessary because the BUS can be operated with or without a device or, in extreme cases, with several attachments. The plug is designed for agricultural use and has a functionality that allows it to be torn off without damage, if z. B. was forgotten when dismantling the attachment to disconnect the connector. Some agricultural machinery manufacturers have also used the connector for non-ISOBUS applications. Other plug connections are also provided for use in the cabin. The DT series from Deutsch plays a major role here. In addition to the InCab Connector (9-pin Tyco CPC plug) for connecting terminals and AUX hardware, a diagnostic connector is sometimes used.

Device plug

z. B. German HD34-24-91PE and HDB36-24-91SE

For extension to the attachment. Without an attachment, the ISOBUS ends in the IBBC (ISOBUS BUS Breakaway Connector) and is terminated there. Since a device ECU is usually more than 1 m away from the IBBC, the BUS must be extended there. However, this also means that the termination must take place at the implement ECU. In order to deactivate the terminator in the IBBC, pin 4 is bridged with 5 in the device connector. As soon as the device is plugged in, a switching element in the IBBC is activated and disconnects the terminator. Usually all connections are used.

Pin 1 GND
Pin 2 ECU_GND
Pin 3 PWR
Pin 4 ECU_PWR
Pin 5 TBC_DIS
Pin 6 TBC_PWR
Pin 7 TBC_GND
Pin 8 CAN_H
Pin 9 CAN_L

In the case of self-propelled machines, this connection is often dispensed with, since it is not necessary to change the working device. In some cases, instead of a full IBBC, only a simple and cheaper plug connection without internal circuitry is installed. It is then possible to change the implement, but the BUS is incomplete if no implement is attached.

As a rule, the IBBC attached to the rear of the tractor feeds the signals TBC_PWR and TBC_GND from ECU_PWR and ECU_GND. Since this is only possible once, an IBBC is used in a possibly installed front socket that does not supply the TBC circuit itself.

BUS extension plug

z. B. Deutsch DT04-04PE and Deutsch DT06-04SE

As a rule, this connector can be found at least on the back of the IBBC (IBRC ISOBUS - Breakaway Rear Connector). All connections must be used.

Pin 1 TBC_PWR

Pin 2 CAN_H
Pin 3 TBC_GND
Pin 4 CAN_L

Diagnostic connector

z. B. German HD10-9-1939PE (tractor side) and HD16-9-1939SE (to the diagnostic tool)

Connections H and J are sufficient for pure ISOBUS diagnosis. Some machines also use other pins, e.g. B. Power supply via A and B.

Pin A not used
Pin B not used
Pin C CAN2_H_Traktorbus
Pin D CAN2_L_Traktorbus
Pin E not used
Pin F not used
Pin G not used
Pin H CAN1_H_ISOBUS
Pin J CAN1_L_ISOBUS

Terminator plug

This connector is used to connect terminators outside of control units. Depending on the structure of the ISOBUS, pins A and C are not used, if they are, then mostly when no IBBC is connected. In this case, the ECU supply at a terminator is used to supply the TBC.

z. B. 6 pin MetriPak 150 connector

Pin A ECU_PWR
Pin B TBC_PWR
Pin C ECU_GND
Pin D TBC_RTN
Pin E CAN_H
Pin F CAN_L

inCab connector

Terminals and input devices are connected here. There are different types of assignment.

inCab as a simple side branch

Some just make a connection as a side branch. Here the maximum length up to the connected device is limited to 1 m.

inCab as an open ISOBUS, requires a loop connector

Others represent an open ISOBUS. Then you need a loop plug that connects the two ends of the BUS lines again. If this connector is missing, the bus is interrupted here.

full inCab, can be switched from the connected device, does not require a loop connector

In the meantime, however, many inCab plugs are fully equipped and are closed in the neutral state. This corresponds to the first case mentioned here. If a device is connected, it may only be 1 m away. If a device needs a longer supply line, it can be connected to pin 1 in the connector ECU_PWR. This opens the BUS, the connection cable can lead it to the device and back on the other side. A loop connector is no longer required because the BUS is only open when a device is connected.

z. B. Tyco / AMP 206705-1 and 206708-01

Pin 1 - (bridged to pin 7 on the device side)
Pin 2 CAN_L in
Pin 3 CAN_L out
Pin 4 CAN_H in
Pin 5 CAN_H out
Pin 6 TBC_PWR
Pin 7 ECU_PWR
Pin 8 TBC_GND
Pin 9 ECU_GND

electric wire

The standard provides for specific cable properties. For example, the actual bus connection within the machine is to be implemented using four-core twisted cables in the colors green, yellow, black and red.

computer

All connected participants are independent computers. The name for this is ECU (Electronic Control Unit). Depending on the task, this name is sometimes expanded to provide a better description (e.g. TECU, Implement ECU ...). The number is limited to 30.

Job computer

The job computer (JR), also known as the implement ECU, is usually located on the attachment. It takes over the control of the machine as well as the display of data and the implementation of operator inputs. Due to the size of the object pool and above all the network management, practically all job computers are at least 16-bit microcontrollers . The C16x from Siemens is very common here. For devices with a large number of sensors, 32-bit microcontrollers are increasingly being used, but these are also significantly more expensive than the 16-bit version. The computers are usually programmed in C, some even in C ++. Another important property of the job computer is the high protection class , which makes it possible to use the devices directly on the attachment without installing them in a particularly tight control cabinet, etc.

If there is more than one job computer on the attachment, these are combined into a working set with a working set master. Only the master has the task of loading an object pool onto the VT.

As a rule, a job computer also has an I / O interface. Current and voltage inputs for sensors are available here, or digital or current-controlled analog outputs for e.g. B. hydraulic valves or servomotors . These inputs and outputs are often designed to be diagnosable, so they can detect whether z. B. there is a cable break or short circuit. It is also planned that the ISOBUS will have a diagnostic interface in order to carry out simple troubleshooting on various devices with a standardized tester.

The problem is that with many implementations a separate object pool has to be created for each user language (English, German, etc.). This takes up a lot of storage space. There are approaches to adapt the object pool at runtime, i.e. to store strings in English and German and, depending on the requirements of the VT, to insert the appropriate ones into the object pool and upload them. Other manufacturers rely almost exclusively on graphics. This reduces the work involved in translations and makes operation more intuitive with a clever design.

GPS / GNSS receiver

A GPS receiver can provide position data for navigation and documentation purposes in NMEA 2000 format. A special transport protocol (FPP) is available for this. Due to the relatively high repetition rate of 20 Hz, this is designed for a low network overhead. For this purpose, the data is divided into several CAN data frames and logically related to one another via a count byte. It can therefore be the case that a recipient has to wait a few messages before he can determine a position, since he has to wait until the count byte is reset again in a new cycle. However, this is only necessary after a system restart or a communication failure and therefore occurs comparatively rarely. Automatic steering systems often still use their own antennas and receivers, as they carry out corrections for greater accuracy, or use multiple GPS receivers on the machine and device. In principle, however, it would also be possible to transmit the GPS data via the ISOBUS for automatic steering.

ISOBUS functionalities

The standard provides for a whole range of different functionalities. Some of these can be implemented within the same ECU. Terminals usually contain a "virtual terminal" and a "task controller".

In order to implement several units of the same functionality, a clear assignment must be made by assigning the function instance. Please note that the function instance is 1 lower than the assigned number. A VT with the function instance 0 is identified as VT number 1. Since some manufacturers specify the number, others the function instance, this can lead to confusion. Each number or function instance may only be assigned once. This assignment for identification should not be confused with the levels mentioned below.

Not every manufacturer makes it possible to define the function instance. Others allow this to be adjusted, but enclose this behind other entries (e.g. assignment of the AUX assignment, this is always done by the primary VT).

A newly connected ECU to the ISOBUS first connects to the lowest number. It loads your object pool onto VT number 1. There the operator can give the instruction in one of the masks of the ECU to display their masks on another VT, provided this ECU supports this. With VT, this can even be done in the middle of work. The operator can therefore move displays from one terminal to another. In extreme cases, this can even be designed completely differently (screen size, language, number of keys ...). A return transfer is just as easy.

Most of these functionalities work according to a server / client procedure. One example is a task controller that is available as a server in the terminal. The devices that register there then work as clients. The use of several servers or clients is possible.

Most of the functionalities are divided into different (evolution) stages. as a rule, higher levels include and extend lower levels. Such downward compatibility also enables devices of different generations to be used together.

Virtual Terminal

The Virtual Terminal (VT), also known as the Universal Terminal (UT), is the man-machine interface of the ISOBUS. It is essentially similar to a web browser that allows access to data on a remote computer. It is a display and control device that is equipped with a screen and several push buttons and possibly rotary buttons. It must have a resolution of at least 200 × 200 pixels and 6 push buttons. A soft button display area of at least 60 × 32 pixels must be available for each button. Therefore, the buttons are usually arranged around the display and parts of the display serve as a soft button area. Usually there are more push buttons and at least one rotary encoder. Partial come touchscreen and numeric input fields used. The display can be in b / w or in color (16 or 256 colors). In 2015, a resolution of 480 × 480 pixels, more than 10 softkeys and multi-touch operation are standard. There are different UT versions that are defined in ISOBUS and each offer a larger range of functions. When a new device is registered at the UT, the communication partners negotiate which version should be used. A UT with version 4 is able to display the pool of a JR that supports a maximum of UT version 3. On the other hand, if in doubt, the JR would have to have another "emergency" pool ready, which is supported by an older UT.

Every device that is connected to the bus and requires a user interface registers with the VT and loads the so-called object pool onto the VT. The object pool consists of one or more masks. A mask can be compared to a website. There are standardized objects such as input fields, strings, bar graphs etc. that can be the content of a mask. The attributes of the individual objects can be changed at runtime by means of corresponding control messages. So it can z. B. the value of an output string can be changed. It is also possible to assign a variable to the content of an output and thus reference a further sub-pool yourself in order to e.g. B. to be able to display a different language by reloading sub-pools.

In principle, it is possible for various attachments to use the VT. You can switch between the individual devices using a navigation button. In some cases, depending on the display size, several devices can be displayed in parallel, or at least the most important information can be displayed simultaneously as a so-called mini view.

To respond to special events, e.g. There are so-called alarm masks in order to be able to react, for example, “spray tank empty”. If an alarm event is triggered, the associated alarm mask appears until it is acknowledged by the user.

Sometimes it is a bit problematic that a mask does not look the same on every VT. This is because z. B. the resolution is different or the colors have been chosen incorrectly. There are now several expansion stages of a UT, so that z. B. not all terminals support VT3 or higher objects.

Another problem is that the VT is usually mounted on the right side of the cab. For tasks where you have to look out to the left, you have the display and control of the machine behind you. In some cases, this can be circumvented with an auxiliary control. These are control elements such as a joystick or switch that can be connected to the bus via an Incab connector and can therefore be positioned relatively freely.

Communication of a VT with an implement ECU

The graphic shows an exemplary communication between a VT and an implement ECU, here e.g. B. a field sprayer shown. The ECU uses the VT as a display and operating module.

The VT only handles objects. Their meaning is irrelevant for the TT. When the user interacts with them, they are passed on to the device ECU. Only this ECU knows all the necessary steps.

Misunderstandings about the available options can also arise from the parallel use of the terms VT and UT. Both denote the same function. But a UT1 corresponds in its capabilities to the VT2, a UT2 to the VT3. At the same time, the VT4 has no equivalent in the UT.

AUX devices

Some operating sequences are difficult to implement using the softkeys, especially when these are implemented as elements on a touchscreen. In order to be able to provide the user with haptic feedback, or e.g. B. to enable operation in the swaying tractor at all, it is possible to use so-called auxiliary controls. These are operating devices such as joysticks, switch boxes or rotary encoders that send the input values as a message to the ISOBUS. You take part in the ISOBUS network as a regular participant. The AUX functions are managed by the VT with number 1 (Function Instance 0). The operating functions are made available by the device ECU. A distinction will be made between AUX-old and AUX-new. All devices involved must use the same variant. A mix of AUX-O and AUX-N is not possible. With AUX-new devices, the user must / can assign the key assignment according to his needs. With AUX-old devices there is a fixed assignment in the job computer of the attachment or a proprietary free assignment is supported by the job computer of the attachment. As a rule, the control levers of tractors can now be used as AUX-new devices. In some cases, the attachments provide a useful pre-assignment for the most common tractor makes. An assigned assignment can be saved in the ECU of the implement and reloaded the next time it is used. A reassignment is then not necessary.

The AUX device is usually connected with a Y cable via the InCab plug.

Tractor control unit

The tractor control unit is also known as the tractor ECU. It is a job computer that sits on the tractor or the carrier vehicle. Usually this is a computer that is connected to the ISOBUS on the one hand and to the tractor's CAN BUS on the other. It accepts data from the tractor.CAN provides this information such as driving speed, PTO speed, etc. in the ISOBUS in the form of messages with the corresponding SPN defined in the standard. In order to offer a simple option for retrofitting solutions, or also low-cost solutions for new machines, various scopes of information are defined that the tractor ECU sends. In the simplest case, these are z. B. only driving speed, PTO speed and three-point position. For higher levels, information such as true driving speed, hydraulic pressures, valve positions, whether the lights are switched on and similar data are added. The Tractor-ECU thus functions as a bridge between the ISOBUS and the tractor bus. The highest level of expansion also allows the implement electronics to control the tractor within certain limits. This can e.g. B. access tractor hydraulic valves or even the steering. So z. For example, a GPS steering system can access the tractor's own GPS receiver via the ISOBUS, convert the position data into a steering signal and then pass this on to the tractor via the ISOBUS. It is still critical here that certain safety regulations on the part of the control unit are necessary. Furthermore, the question of liability must also be clarified, who has to pay for damage that z. B. could arise through automated false conditions.

Another task of the tractor ECU is power management. If the ignition of the tractor is switched off, the tractor-ECU sends a message to the implement-ECU that the power supply will be switched off in two seconds. The implement-ECU can now extend the power supply for a further two seconds with a message until a new warning comes from the tractor-ECU. This can be continued indefinitely. This can be useful if z. B. electrically driven locking processes are still carried out, which must not be interrupted, or possibly after switching off the tractor engine, the pressure must be released from the system. This also enables secure data storage and shutdown.

Sometimes the tractor ECU also uses the VT to show the driver status information about the tractor. So it behaves in part in the same way as an implement ECU.

Even in 2016, far from all tractors will be delivered with a tractor ECU. The tractor ECU is then often implemented in the VT as a logical control unit. The necessary signals from the tractor are picked up via a standardized signal socket or supplied by retrofitted sensors.

Other low-cost solutions dispense with the connection to the tractor entirely. Most devices only need the driving speed. Since this is only available from the tractor itself with slip, it represents a large error factor. A radar device can be used to determine the true speed. Since a GNSS receiver is usually also connected, the true speed determined there can be used instead. In this case only this function of the TECU is emulated. Further data such as PTO speed are then not available. On the other hand, these are mostly monitored on the device itself.

Task controller

The task controller (TC) represents the interface between the farm management system and the device control.

Task controller basic

In the simplest case, it documents the work carried out as TC-BAS.

Task controller Geo

As a TC-GEO, he can transmit order data to the implement. All data that are site-specific are kept here. This includes maps of where work has already been done, how much should be spread, what was actually spread, as well as field boundaries and lead tracks.

It is planned that he will even take over the control of the tractor. For example, he can determine the application rate of pesticides depending on the position. For this purpose, an ISOBUS-compatible device has a description file in which e.g. B. says that the field sprayer has a working width of 18 m and 3 sections and can apply between 100 and 1000 l / min. With this file, a work order is created with the help of a field map, position data and any existing field-specific data on the pest pressure of the field to be worked. This is transmitted in digital form to the task controller on the tractor. If the driver is now standing in the field with the sprayer, the task controller can process the order after the driver has given approval. Depending on where the driver is driving, more or less pesticides are applied according to the data. At the same time, the application rates and positions for quality assurance and documentation are saved and later entered into the field map. This function, also known as Variable Rate Control , can also be used for several products that are applied at the same time. So z. B. The application rate of seeds, underfoot fertilization and microgranulate can be adjusted simultaneously on the basis of different setpoint maps depending on the position.

To do this, the implement ECU only has to transmit the device description with the corresponding control channels to the task controller. For different application techniques, different references are used in the order file via so-called DDI. B. to distinguish between solid and liquid application. The units used are defined to avoid conversation problems such as t / ha instead of kg / ha.

The orders are transferred as XML files. The "TASKDATA.XML" file serves as an access point for the task controller and for the read-back for the farm management system. This can refer to further XML files and application maps in two different binary formats. Prescription maps can be made available directly in the XML file or this binary grid data. With grid type 1, the application quantities are defined in the XML file and referenced in the binary file only via a single byte. With grid type 2, 4 bytes are available for a real application value. A reference in the XML is then only necessary for additional information such as the application quantity outside the field or if the position is lost. Furthermore, an application map can also be in the form of polygons within the XML file.

Section control

Can the attachment switch sections of its working width, e.g. B. Nozzle sections on a field sprayer or throwing distance on an artificial fertilizer spreader, their control can be automated depending on the position and the area already worked. In the case of a field sprayer, for example, the area that has already been treated is recorded and the corresponding sections of the working width are turned off when they are passed over again or when there is a partial overlap. This leads to greater accuracy and noticeable relief for the driver and can therefore save considerable amounts of fertilizer or pesticides. To implement the function, the JR loads a machine description onto the terminal, which is read there by the TC / SC. Depending on the available sections and settings for the degree of overlap and delay times, the terminal can now generate control commands for the sections based on the current position. This functionality is also made available by the task controller as TC-SC.

File server

The file server (FS) provides all devices connected to the ISOBUS with storage space for configuration or information data. Rudimentary commands of a file system are made available. This was once possible on an internal memory, but also for the synchronization with the field map on the farm PC via a portable memory. While storage was initially carried out on floppy disks and later often on CF cards, there is now a clear trend towards USB sticks or even wireless networks based on GSM or WLAN.

Network management

“Network management” is the way in which the access options to the bus are regulated (who can send data to whom and when?). These are processes that the user usually does not notice - at least not as long as there are no conflicts when the different devices access the bus.

In an ISOBUS system, devices can be connected to the bus and also disconnected again during runtime. This is only possible because there is a dynamic address assignment. The so-called address claim ensures that each participant is given a unique name. Each participant must also maintain a list in which it is recorded who is currently holding which name and which messages the participant must receive. This is the reason why hardware identifier filtering such as B. is basically impossible with Messageobjects.

The ECU 1 sends an Address Claimed with its name as a broadcast message. The other ECUs that are online then report with their address and name. Then the ECU 1 knows that it can occupy the address 15, since its name has a higher priority than that of the ECU 2, which has occupied the address 15 up to now. It does this with an address claimed with the address 15. The ECU 2 then sends a Cannot Claim Address and receives the address zero. Next, the ECU 2 must either search for a new address independently or be assigned a new address by another participant with a command address. This process takes place every time after a power up or when a new participant joins, e.g. B. if an implement is connected to an ISOBUS network. Mechanisms that z. B. Profibus, another field bus, are provided in order to avoid an overload on the bus at the beginning by the individual participants waiting a time depending on their serial number, are not implemented. With the J1939 and ISOBUS, arbitration takes place in such a situation, since it is layer 7 on top of the CAN layer. An Address Claimed can also be sent to an individual participant as a P2P message. This can be useful to infer the function from the name. An ISOBUS participant should be able to assign himself a new name in case he has to give his name during an address claim. This is very different from a J1939 network, where this capability is far less important.

The microcontroller is heavily burdened by the network management, because every incoming message triggers an interrupt and it must be checked whether it is significant for the participant. The norm is kept here in such a way that even very unlikely cases are covered. In some cases, this can hardly be implemented, so basically no software solution offered is really compliant with the standards. As a rule, however, this has no effect on the operating behavior. Situations are problematic in which the recipient or sender change their name during a data transfer with a transport protocol. This usually leads to the data transfer being aborted.

Transport protocols

A special feature of ISOBUS is that, for a fieldbus, unusually large amounts of data must be transported between the individual participants in the MB range. The CANBUS is initially only suitable for data volumes of up to 8 bytes. For larger amounts of data, these must be divided into parts that can be transported with a CAN message. Typical data that are transmitted are e.g. B. an object pool for the VT, order data for the TM or GPS position data.

A total of 4 different transport protocols are used for this:

CMDT

Connection Mode Data Transfer is a protocol adopted from J1939 for P2P communication between control units. A maximum of 1785 bytes can be transferred per session. The protocol offers possibilities to send certain parts of the data volume again or to insert a pause in the transmission.

BAM

The Broadcast Announce Message is the global equivalent of the CMDT, however, due to its principle, without its control options.

ETP

The Extended Transfer Protocol is an ISOBUS-specific extension of the CMDT in order to be able to transfer data volumes of up to 117,440.512 kB with a pointer concept. This is particularly useful in the case of graphically complex object pools. The definition takes place in PART 3 (from version 2014, previously Part 6) of ISO 11783.

FPP

For the fast cyclical sending of data, usually GPS data, the Fast Packet Protocol was adopted from the NMEA 2000. In contrast to the other transport protocols, it has a very low overhead and thus ensures the least possible load on the bus.

Interface for the user and problems of the ISOBUS

New features relevant to the user are the standardized plug connections for signals and electrical energy between the tractor and the attachment (which should be available both at the rear and at the front of the machine), the Virtual Terminal (VT) and the Task Controller (TC), but also the can be integrated into the VT. The problem with ISOBUS is that the standard allows the developer a relatively large amount of freedom. An object pool that looks great on one VT is displayed so badly on another that even the usability can suffer. Here the developer is required to find a representation that is suitable for all VTs as possible. Some of the devices are also not entirely ISOBUS-compliant, so that the bus does not work under unfavorable circumstances. With the increasing spread of ISOBUS-compatible tractors, it is also becoming more and more interesting in terms of costs for implement manufacturers to equip their implements ISOBUS-compatible. For this reason, it can be expected that these problems tend to decrease in the long term.

Opensource and ISOBUS

At the Technical University of Munich it was already recognized in the days of LBS that the system could be made more widely available by creating an open source LBS library. A library was created that could later be adapted so that it was ISOBUS-compliant. When the research project expired, the library was taken over by OSB AG and continues to be actively maintained there as ISOAgLib. It is freely available under a GPL-compatible license. Basically, ISOBUS applications can be created with open source tools alone. There is a certain restriction with crosscompilers for job computers. Commercial products are often required here. Another open source project comes from Finland. A mask creation tool was developed here. By and large, it is compatible with the mask description of ISOAgLib. The advantage is that with the tool you can immediately see what a mask looks like. With ISOAgLib, the mask is described with an XML file (similar to HTML) and the result can only be seen on a real or simulated VT - or with the help of commercial mask creation tools.

ISOBUS and functional safety

When developing electronic systems that are used in agricultural engineering, ISO25119 should be observed. The standard defines requirements and processes that are necessary to bring a system onto the market in which electrical functions control safety-relevant functions. If the ISOBUS is used here, usually as a so-called input system, ISOBUS components may be in the safety-critical path. For this purpose, guidelines have been drawn up by the AEF as to which requirements must be placed on ISOBUS components in order to be able to use them in an application in which they are part of a safety-relevant system.

compatibility

In order to ensure compatibility of the JR, terminals, TC, etc. with regard to the above-mentioned problems, the following approaches have been established.

AEF test

The AEF test is an automated sequence of tests, the aim of which is to ensure that the properties specified in ISO 11783 are met. Both the hardware and the functionality of the software are tested. The aim is that two tested components, which are thus standard-compliant, work together without any problems. The test composition differs partly depending on the type of device to be tested. For example, the functionality of the section control server is tested on a job computer, while the client functionality is tested on a terminal with SC function. The scope of the tests is defined in AEF working groups and then gradually incorporated into the scope of the test. The tests can be carried out directly by the manufacturer. For an entry in the AEF database and permission to use a corresponding sticker, however, the test must be carried out by a certified test laboratory. The test must be repeated each time a new software version is released by a device. Based on the test results, the compatibility of the agricultural machinery dealer or the buyer can be checked in advance with a database before buying a device or tractor. In addition, the AEF acts as an intermediary in the event of problems with devices from different manufacturers and establishes contact between the parties involved. For this purpose, a ticket can be created on the AEF website, whereupon the manufacturers involved must analyze the problem within an agreed time and, if possible, solve it.

Plugfest

A Plugfest is a meeting of ISOBUS developers at which the compatibility of the individual devices with one another is tested. The individual developers of the companies bring their job computers and VTs with them and see whether the display and function are correct. The plug festivals are regularly organized by the AEF . But there are also plug festivals in other European countries, America, Japan and South America. They usually take place in connection with a meeting of the working group for the standard or an AEF working group. They are important because although there is a simulator for the various VTs, it can never represent all the peculiarities of a VT. It is much more effort to design the object pool so that it is compatible with as many VTs as possible than to implement the actual device control on the ECU. Object pools are often also optimized for one, often manufacturer-specific, VT and only basic compatibility with the other VTs is guaranteed. Manufacturers of VTs also use the Plugfest to track down bugs in their VTs. Participation in a Plugfest is usually chargeable for commercial users. Lectures or company presentations on aspects of ISOBUS are sometimes held. As a rule, one Plugfest is held each year in Europe and one in the USA at often changing locations. Up to 250 participants from over 80 companies are present.

literature

ISO 11783, Beuth Verlag
Smooth communication between tractor and attachments, in: ElectronicAutomotiv 12, 2003

Web links

Basic information about LBS:

On the way to a high-tech product - magazine article

Basic information on ISOBUS:

Further information:

Individual evidence

↑ ^a ^b Beuth Verlag (Ed.): ISO 11783 Part 6 . Part 6.
↑ Beuth Verlag (Ed.): ISO11783 Part 9 . Part 9.
↑ ISO11783-Part10
↑ ISOBUS Data Dictionary - DDEntity. Retrieved January 25, 2018 .
↑ ISO11783-Part5

[Part_6-1] Beuth Verlag (Ed.): ISO 11783 Part 6 . Part 6.

[2] Beuth Verlag (Ed.): ISO11783 Part 9 . Part 9.

[3] ISO11783-Part10

[4] ISOBUS Data Dictionary - DDEntity. Retrieved January 25, 2018 .

[5] ISO11783-Part5