Farmers will often have a single tractor which they use for many different types of farmwork. A tractor alone does not do any work, it is essentially always paired with, powering, and/or moving something else, an implement mounted on its front or rear. It is particularly common in Europe, where there are many small regional manufacturers, that a farm contains tractors and implements from many different companies. The basic purpose of ISOBUS is to enable electronic communication between the tractor and the implement(s) attached to it. The two main aspects are that it must be possible to connect devices from different manufacturers, and that it must be a plug-and-play system that works without requiring any configuration by the end user (the farmer).
Notes
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Introduction
Farmers will often have a single tractor which they use for many different types of farm work. A tractor alone does not do any work, it is essentially always paired with, powering, and/or moving something else, from a simple trailer that holds produce for transport, to sophisticated, hi-tech machines with advanced features such as artificial intelligence (AI)-based automatic spraying technology. These machines are mounted on the front or rear of the tractor and are known as implements. It is possible and even probable that the tractor and the implement are produced by different manufacturers. It is particularly common in Europe, where there are many small regional manufacturers, that a farm contains tractors and implements from many different companies.
ISOBUS is the industry-given name for devices that have been certified by the Agricultural Industry Electronics Foundation (AEF) as compliant with the ISO 11783 standard series which defines a bus system built on top of 250 Kbit/s CAN 2.0B. The ISO 11783 foundations were laid in 1987 when the development of its predecessor standard, DIN 9684:2–5, was started. Even if the original ideas are from 1987, the official launch of ISOBUS technology for public use was not until November 2001. The basic purpose of ISOBUS is to enable electronic communication between the tractor and the implement(s) attached to it. The two main aspects are that it must be possible to connect devices from different manufacturers, and that it must be a plug-and-play system that works without requiring any configuration by the end user (the farmer). As technology has advanced, ISOBUS has needed to keep up; in modern farming there is a need for automation control systems, big-data, detailed analysis by agronomists, and more [1].
Advertisement
The ISO 11783 standard series is split into 14 parts which define all OSI layers from the physical to the application layer. The ISO documents are used by engineers who want to have their products certified as ISOBUS-compatible by the AEF. To aid end users, the AEF certifies ISOBUS products against nine functionalities. A functionality is “a product which can be explained to the end user as a separate ‘module’ on the ISOBUS.” [2].
The most interesting functionalities are:
The Universal Terminal (UT): A screen in the tractor cabin (commonly touchscreen) which allows the farmer to interact with the equipment (Fig. 1). Each implement can make its own GUI which is automatically uploaded to the UT when the implement is connected.
Fig. 1
The inside of a modern tractor cabin. The main terminal can be seen behind the joystick
×
The Task Controller (TC): A computational device which can control the implements connected to tractor to enable GNSS-based automation and data exchange of farming processes. This commonly involves turning applicator sections of the implement on/off and varying the application rate as the machine moves through the field. Defined in Part 10 of the standard [3].
Tractor-Implement Management (TIM): A protocol to allow the implement to drive the tractor (set the speed, steer, etc.). This improves accuracy because implements could have special sensors to detect their optimal conditions as they travel through the field, e.g., sensors to detect if the quality of work is suffering over a certain speed, or sensors to detect if the implement is correctly positioned within the crop row.
In addition to the network messages that are sent during field operations, the ISO 11783 standard series defines a single comprehensive data exchange file format based on XML to allow the transfer of data between products from different manufacturers. This so-called ISO-XML file format encapsulates “tasks” (individual work packages); in their simplest form tasks comprise the application of a single product in a single field, however, more complex use cases are also supported. The tasks are first planned in detail in a Farm Management Information System (FMIS) (generally software running on a PC or in the cloud), transferred to the tractor with selected media (e.g., USB stick), and at the end of the day farmers may move the documented work back to the FMIS for bookkeeping purposes.
Plug and play
The most important piece of information for understanding the background of ISOBUS is the requirement for cross-manufacturer, plug-and-play capabilities. When farmers plug their new implement into their new tractor, all communication must organise fully automatically without any user configuration. Farms work on tight deadlines and need reliable machinery which is easily available for the work at any time—and without having special IT skills. ISOBUS was and is developed with the requirement of truly (hot) plug-and-play because any system that takes too long to connect would impact profitability.
Advertisement
This requirement has led to strict standard interface definitions and automatic configuration at different levels of communication such as: bus arbitration at the data link layer, automatic dynamic addressing at the network layer, process data driver exchange at application layer, et cetera. True plug-and-play is required for both the user experience, and also due to the missing link to the Internet as the ISO 11783 foundations were laid in the early 1990s and no automatic driver download was possible that time—which remains true today in several locations where tractors are used. The key points are:
The end users of this technology are agricultural workers who are not required to be IT/network savvy.
The farms want to mix and match different brands.
Breaking backwards compatibility is not accepted by the market because farmers purchase their (expensive) machinery primarily for its physical/mechanical characteristics and many farms will keep equipment maintained for many years.
Universal Terminal (UT)
The Universal Terminal (UT) is software which generally runs on a small (5″–12″) display in the tractor cabin. It is defined primarily in ISO 11783 Part 6. All of the large tractor companies integrate their own UTs which can come built-in as an option for the tractor. Alternatively, stand-alone UTs exist from implement manufacturing companies and independent electronics companies.
Built-in displays may offer the driver the option of controlling proprietary aspects of the tractor outside of the functionality defined by ISO 11783, but the main purpose is to allow implements to upload their own GUI to give the driver easy control. One can imagine how the situation might be without ISOBUS: the driver would need separate, proprietary control boxes for each implement; one for slurry spreading in the morning, another for ploughing in the afternoon, a third for moving products in a tilt trailer in the evening, and so on.
The UT concept was first published as an international standard in 2004 and electronics were less powerful (and more expensive) than today. Because of backwards compatibility, the way that the UT works is the same today as it was back then (with some updates):
1.
There is an initialisation procedure where the UT and the implement query one another’s capabilities (memory, UT version).
2.
The implement uploads its Object Pool to the UT (further explained below).
3.
Now the UT can display the implements GUI design.
4.
Each object on the display has a unique ID. When the user presses buttons, inputs text or numbers, etc., the UT sends information over the CAN bus about the object ID and the new value of the object. The reverse is true when the implement wishes to update values on the screen.
The GUI design is uploaded as an object pool. The ISO standard defines several object types which can be used: shapes, buttons, input/output fields, colours, alarms, simple audio tones, and more. The object pool contains the information about which object types should be drawn and where. In this way the format is standardised; however, the specific implementation of how exactly each field/shape should look can vary slightly between implementations (Fig. 2).
Fig. 2
Image of a universal terminal (UT) display. The large area on the left is a square-shaped data mask where information is displayed. The right side is reserved for soft-key icons which are used for navigation, and control of the machine. For each soft-key, a mechanical push button is associated—today mechanical buttons are commonly replaced by touch-screen capability
×
Task Controller (TC) and Farm Management Information System (FMIS)
The Task Controller (TC) is a device which handles various aspects of automation; it is commonly bundled-in with the UT but not always. The AEF splits the TC into three functionalities which can be sold as separate products/features or together.
Basic (TC-BAS):
Simple data logging without geolocation (GNSS). The user can export data such as the total amount of product applied, reference information such as who was the driver, description of the work, etc.
Geo-based (TC-GEO):
The logged data can be referenced to global coordinates (WGS84 used in GNSS). The user can export data showing where product was applied in the field and how much.
The user can predefine a prescription map1 which describes the desired application rate for different areas of the field. Not all areas of the field are the same, some soil will need more nutrients, some less (Fig. 3).
Fig. 3
Prescription map created with a software tool. The field is split into grid squares which each require a different level of product applied to them
×
Section Control (TC-SC)
Sections of the machine can be turned on or off by the TC automatically with the help of GNSS positioning. The purpose is to minimise the amount of the field which is either missed (gaps) by the applied product or is double-dosed (overlaps)—to accomplish full coverage without overdosing.
The future of ISOBUS
In the past 35 years the ISO 11783 standard series has evolved to become the sole standardised solution in tractor-implement communications. The decision to use a CAN bus originates from the year 1988 and this 34-year-long era of relying on a single physical media and data link layer is exceptionally lengthy for any modern communication technology. While the decision to go for CAN bus decades ago provided longevity, each technology ages and new innovations require more speed and/or robustness [1].
The current technical work on ISOBUS is split into several streams. Firstly, several AEF groups/taskforces are working to update the ISO documents and improve the existing ISOBUS functionalities by releasing new generations, improvements, and recommendations. For the Task Controller there is ongoing work to finalise TC Generation 2 (Version 4 of the ISO document) which will allow more complex implement types to be controlled among other improvements.
Secondly, the AEF is working with contributions from wider heavy-vehicle industries to develop a so-called “high-speed ISOBUS” (HSI), built on top of gigabit single-pair Ethernet (IEEE 1000BASE-T1) [4]. Changing the physical layer from CAN bus to Ethernet brings not only more bandwidth, but also more opportunities to utilise IP-based software technologies. The first steps include ideas for tunnelling CAN messages over IP, so that the speed boost of the physical layer can be realised (albeit not to its fullest) as soon as possible. By using CAN tunnelling, manufacturers can easily port their existing software over to the new network, and the years of lessons-learned which are baked into the current ISOBUS can be retained.
While CAN tunnelling will be an improvement, the actual benefits of an IP network are achieved by using proper middleware which would allow easier software development. However, the AEF’s requirements for middleware are special due to the plug-and-play nature of agricultural machinery—without any Internet connectivity. Achieving plug-and-play in all layers of communication and application once again requires strict standardization.
One of the first new features of high speed ISOBUS is the introduction of plug-and-play connection to cameras because this is not possible over a 250 kbit/s CAN bus. Soon implements will be able include built-in cameras which the driver can observe in the tractor cabin, or via remote access. Here, we can expect challenges, most likely relating to plug-and-play. How should different resolutions be handled considering that different clients may have very different hardware, from embedded controllers to large data centres?
The development of the future HSI will bring large advances and a multitude of opportunities. Some of the expected areas of interest are outlined below:
Improved information modelling
The information modelling of current ISOBUS implements allows them to share details about their physical properties. However, newer information models such as those provided by OPC UA are more fully featured [5].
Improved connectivity with Internet services
Improved connectivity could be used for remote condition monitoring or to automate compliance with legislation, such as the German Düngeverordnung rules which governs the requirement for farmers to report how much organic fertiliser they use.
Control of more complex and advanced machines
New levels of control granularity will become possible that was not previously because of the slow speed of the CAN bus. For example, each nozzle of a 30-meter-wide sprayer could have its flow rate controlled independently, with update rates over 10 Hz. This will open up space in the market to take advantage of more complex machines.
Advanced functional safety and data security
One factor holding back automation in agriculture—as in many areas of engineering—is functional safety. With the increased bandwidth of the network, more features can be added to address the challenges with functional safety.
There will be a more reliable connection and there are opportunities to improve in areas like trust, authentication, and non-repudiation.
Final remarks
ISOBUS is going through some exciting changes. As it has grown and the ecosystem has developed, more and more data is being produced, more compatible machines are available, and farmers are more aware of the value of automation and the value that is contained in their data. Simultaneously, talks are becoming increasingly serious about the next generation of ISOBUS which will require a large amount of expertise that was previously not commonplace within the Ag industry with more advanced networking problems to be solved. Even if additional security mechanisms are added to the next technology backbone, the standard will be kept open so that small and large industries around the world can join in developing components for the ISOBUS ecosystem. The key element of this success story from the beginning has been an open standard.
Funding
The project is supported by funds of the Federal Ministry of
Food and Agriculture (BMEL) based on a decision of the
Parliament of the Federal Republic of Germany. The Federal
Office for Agriculture and Food (BLE) provides coordinating
support for digitalisation in agriculture as funding
organisation, grant number 28DE112B18.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
Publisher’s Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Hauptaufgabe dieser Zeitschrift ist die Publikation aktueller, praktisch verwertbarer Informationen über technische und wissenschaftliche Fortschritte aus allen Bereichen der Informatik und ihrer Anwendungen in Form von Übersichtsartikeln und einführenden Darstellungen sowie Berichten über Projekte und Fallstudien, die zukünftige Trends aufzeigen.
