History

The name ISOBUS was coined a short time before the public launch at the Agritechnica exhibition in Hannover in November 2001. The current ISOBUS is based on the ISO 11783 standard series, which has been developed by ISO TC23/SC19.

The origins of ISOBUS trace back to the year 1987, when the German industry and academics recognised that the "DIN signal connector" (the famous short-term solution decided upon 1986), nowadays known as the ISO 11786 standard, was not sufficient for more complex systems than a sprayer or spreader reading the wheel speed from the tractor for 1980s "multi-functional computers". The fundamental decision was made in September 1987 to build the communication between tractor and implement around "bus technology". At that time, this approach meant sharing the same physical layer copper wires for all ECUs connected. Hence, token-ring, star, and other typical topologies for 1980s communication technology were put aside and the focus was to find the technology to realise a "bus system". [1]

In May 1988, the same committee decided to adopt CAN bus (version 1) technology, which had been developed and released by the Bosch company a few years earlier for automotive purposes. The bus speed was fixed at 50 kilobits per second, or 50 kbaud. This was the beginning of the communication. This technology was described in the DIN 9684 series, parts 2-5. This technology became available for farmers under the acronym "LBS", according to original German name "Landwirtschaftliches Bus-System". 50 kbaud was found to be sufficient for the microcontrollers of that time, as the processing power of each message was also limited by the processors of that era. [1]

In the late 1990s, the speed of the bus was ramped up to 125 kbaud, still with CAN bus. This was known as "LBS+". The concepts of Tractor ECU, Virtual Terminal (User/Virtual/Universal) and Task controller originate from the DIN 9684 series, or LBS. [1]

The current ISOBUS, based on the ISO 11783 series, was developed jointly with SAE (and their J1939 series) in the 1990s. Due to harmonisation, it was jointly decided to set the CAN bus speed at 250 kbaud. Based on the Bosch specification, with a 40 m bus length, the maximum speed should be 125 kbaud. However, research in laboratories proved that the next increment, 250 kbaud, would be possible by setting mild slopes for signal transitions and other adjustments in physical layer. This fixed speed has been running the current ISOBUS workhorse since 2001, for the last 25 years without modification.

Advances in tractor engineering

Whilst 250 kbaud with non-deterministic CAN bus provides a sufficient backbone for basic communication, such as scalar process data exchange between nodes and a basic graphical user interface with numeric updates and events, it cannot scale much beyond that. For example, a real-time transfer of array data (such as camera pixels) or a fast update rate over 100 Hz would easily overload the whole bus. The largest commonly used real-time array communication is section control, a vector of 256 on/off values for command and feedback.

The need for a faster backbone was already observed in the mid-2000s. Similarly to how CAN bus came to the agricultural machinery industry from automotive technologies, developers of tractor internal electronics architectures followed these trends. Tractor internal electronic communication is easier to realise due to its closed nature and no need for plug-and-play. In the mid-2000s it was typical that the number of functions in tractors increased rapidly, e.g., the number of hydraulic auxiliary valves installed per tractor. New functions were introduced, such as integrated automatic guidance systems, which brought positioning devices, graphical displays with maps et cetera. Besides new functions, existing functions also utilise improved sensors, actuators and user interface technology, which require more dimensions, more rate, or more resolution. All of these require wider bandwidth for the communication.

Faster communication needs for connecting tractor internal components were set, for example, by electric drives, as torque vectoring control systems required a fast rate, 1000 Hz or more update rate.

Whilst one CAN segment was the typical architecture for tractor internal electronics communication, in the mid-2000s the typical architecture was already 2 different CAN segments (plus one more for ISO 11783), and later up to 5 CAN segments were seen interconnecting ECUs into a system, with various CAN baud rates.

As CAN bus is limited to a maximum of 1000 kbaud with the classic version, the tractor industry was already starting to look beyond CAN bus in the mid-2000s. The automotive industry developed new technologies at that time (e.g., FlexRay), but also industrial automation evolved to Ethernet-based versions (e.g., Profibus extended to ProfiNet, Modbus to Modbus TCP/IP, DeviceNet to Ethernet/IP). The industrial automation domain and its providers actually had numerous parallel adaptations of industrial Ethernet, with different varying properties. Going beyond CAN bus at that time was not due to a lack of technology, but too many options, of which many were not interoperable. Likely, no technology was perfect, and adapting these would have required developing proprietary hardware for embedded tractor electronics.

The tractor industry was also looking closely at advances in software development architectures and processes in the automotive industry. For instance, AutoSAR was developed hand-in-hand with certain communication technologies; the leap from "CAN bus" architecture and off-the-shelf ECUs to something else became even more complex.

Towards faster ISOBUS

Whilst future tractor electronics was an active research topic, this naturally also led to similar thoughts about the impact on tractor-implement communication in multi-brand systems.

One of the first published efforts to boost ISOBUS speed was the integration of FlexRay (10 Mbaud dual-channel automotive bus) alongside with CAN bus, published at SAE congress in 2006 by Marzani et al. [2]. This paper presented a hybrid FlexRay + ISOBUS network architecture. Their prototype demonstrated that time-triggered, deterministic FlexRay could help achieve better real-time control, improving the reliability and safety of the current ISOBUS. However, they concluded that FlexRay, with its rigid scheduling, introduced additional complexity and was not suitable for plug-and-play networks, as ISOBUS foundationally was.

John Deere and Rauch undertook a publicly funded project, "Real-Time Ethernet Communication between Tractor and Implement for Automation of Tractor-Implement Applications", from December 2007 to May 2010, funded by the German ministry of agriculture. This project focused on finding a new communication backbone beyond CAN bus to realise real-time control of electric drives in implements, with field-oriented control of permanent magnet synchronous motors. Typically, these kinds of applications require a sample time between 1–10 ms, and with the current ISOBUS, this is impossible to realise in a stable manner. This project surveyed available technologies beyond CAN bus and, already at that time, 26 different industrial real-time Ethernet variants were found (e.g., Ethernet/IP, Powerlink, Sercos-III, Profinet, EtherCAT, RTSP…). For this project, they selected EtherCAT to be used for prototyping, as it natively provided 100 μs sample time and low jitter for the electric drive use case and supported sufficient cable length. As the focus of this project was on single-implement use (fertiliser spreader or sprayer), the EtherCAT master-slave architecture was sufficient. In addition, the project demonstrated "tunnelling" ISO 11783 messages over EtherCAT with less than 1 ms delay. However, this project did not address more general requirements such as multiple implements, hot plug-and-play, topology changes, or multi-implement coordination. [3]

This project was a natural evolution of the development of tractor-internal communication beyond CAN bus. John Deere had already moved to high voltage within the tractor, in the tractor family 7x30 E Premium (models 7430, 7530; launched in 2007 with DLG Gold Medal, in production 2009–2011). The original motivations for John Deere E Premium included electrification of the engine cooling fan, air conditioning compressor, air brake compressor, and coolant pump. In 2011, the introduced successor model 6210RE used EtherCAT technology. These systems pushed the needs beyond CAN bus. Hence, the technology leap followed the earlier attempts: tractor-internal first, tractor-implement second. [4]

ISO committee 2012-2013 "Search of the best Industrial Ethernet"

ISO TC23/SC19/WG1, responsible for the ISO 11783 series, had several times discussed the need to look beyond 250 kbaud CAN bus between 2009 and 2011, under the agenda items "other business" or "open discussion topics". Finally, in the 50th WG1 meeting on 28 March 2012 in Frankfurt, the ISO working group decided to formalise the work by establishing a new Task Force to coordinate next steps. At this point, CAN FD had already been announced and was considered as one direction, and the existence of BroadR-Reach was also acknowledged, and first demonstrations of how to tunnel ISOBUS over Ethernet using UDP had been done. Giorgio Malaguti (IMAMOTER) volunteered to lead this Task Force, whilst in the meeting, the members Jacob van Bergeijk (AGCO), David Smart (John Deere), Massimo Ferretti (Re:Lab), Martijn van der Bijl (Kverneland), and Timo Oksanen (Aalto University) were selected.

The active period of this task force was between April 2012 and November 2013. During this period, the task force explored various industrial Ethernet solutions and tried to compare them on paper. The requirements for the next generation were not clearly defined, but the task force assumed that principles and functions should be similar to those in ISO 11783, e.g., open network, clear addressing scheme, transparent diagnostics, both point-to-point and broadcast messaging architecture. The task force also had knowledge of the bottlenecks of the current ISO 11783, such as the capacity limit for task controller performance or lack of advanced objects in the virtual terminal (e.g., enabling animations or better graphics), and naturally requirements to seek something better than the existing CAN-based system existed. However, this group did not address cybersecurity as a requirement but tried to seek a solution which would keep ISOBUS open, preferably based on licence-free tooling and technology and avoiding single-vendor technology. In addition, the task force also observed the lack of plug-and-play in several industrial Ethernet solutions, which limited the options for taking an SAE J1939-type low-layer stack (for OSI layers 1–4) off-the-shelf. Most of these technologies were developed for fixed systems in industrial automation or automotive, and in all of these, it is typical that either the system is configured by engineers or there is no configuration after assembly. In farm machinery, since 1987, from the beginnings of LBS, it was known that these machines are multi-brand and the integrator is typically a farmer, and everything should be auto-configured.

DIN mirror committee "Industrial requirements"

Each member nation of ISO has its local standardisation bodies following the work. Nations with the most active standardisation areas have their "mirror committees" for ISO committees, to discuss locally the work done in the international ISO committee. In this field, since the 1990s, one of the most active mirror committees has been in Germany, due to a large population of small and medium enterprises. The mirror committee for SC19 is known as "TAE", hosted by VDMA. The German mirror committee had paid attention to ISO WG decisions and decided to establish its own project group, "High Speed Networking", to align with the ISO task force. This project group was founded at the 19 September 2013 TAE meeting. The project group was led by Andreas Möller (ANEDO).

This project group emphasised a rapid decision on the technology and rapid prototyping, in order to make the standard quickly available. The group tried to find existing technology that would meet obvious requirements for connectors and cables (mobile vehicle, with power supply integrated), availability of hardware for product development (e.g., ECUs), sufficient bandwidth, and also functional safety. In 2013, functional safety was on the table of all engineering departments, and thus it was very logical to place hopes that the new technology would help with the challenges that CAN bus and ISO 11783 had raised.

Also typical of that era, this group did not put too much emphasis on cybersecurity but tried to prioritise plug-and-play. Emphasising plug-and-play was very natural, as, before 2013, the industry had spent a lot of effort to improve this aspect of ISO 11783 interoperability in the field. This was just a fresh lesson learnt at that point in history: how hard business is if the quality of the standard is not sufficient.

The German project group had set a goal in September 2013 that the new technology must be clarified within a year of that point, and within another year, a prototype should be realised. This spirit was similar to the decisiveness in the late 1980s when LBS was created – clear and fast decisions. ISO 11783 also had a similar golden era for clear and fast decisions in 1999–2003, when Tractor ECU with three classes, Virtual Terminal, and Task Controller were all finalised. Whilst the industry had succeeded twice in agreeing on common technology, this was seen as possible once again.

The German mirror committee presented its initial work at the ISO WG1 meeting in November 2013 in Hannover.

AEF era 2014-2017 "Era of new beginnings"

Between 2012 and 2014, the transition occurred to move all technical preparation of ISOBUS-related standards from ISO Working Group and Task Forces to AEF (Agricultural Industry Electronic Foundation e.V.). This organisational decision also impacted the preparation of the "faster ISOBUS". In 2014, a new Project Team was founded for AEF under the name "High Speed ISOBUS", project team number 10. The core of this project team was formed from the members of the German mirror committee and other experts from AEF. Thus, the ISO WG1 Task Force was disbanded. The first project leader under the AEF High Speed ISOBUS project team was Andreas Möller (ANEDO). Obviously, the work continued more to the way, which the DIN mirror committee had started, and the work items done by ISO Task Force were not continued or discussed any further. Therefore, it is fair to say that AEF project team was actually built on foundations of DIN mirror committee, than ISO Task Force.

The first meetings were used to discover the architectural wishes, clarifying the relation to the high-voltage power interface, collecting key parameter wishes (such as latency, bandwidth, power supply), and relation to the camera system. Technology exploration continued, e.g., to CAN FD. The naming "High Speed ISOBUS" was coined in the meeting in summer 2014, whilst only considered as an internal development name, not necessarily intended for the final market name. In early 2015, an important decision was taken to say that the future architecture is "dual stack", which means that CAN will stay as one backbone and the faster technology should be the parallel backbone. Whilst this decision was a clear architectural decision, later years have attempted several times to realise a single backbone with faster technology and solve backwards compatibility to CAN bus with various gateway or tunnelling concepts. At that time, AEF also had a separate team for camera systems, which had focused on an analogue interface, and eventually the goal was to move towards a digital interface.

The project team was aligned with a "wired first" strategy and pushed all ideas related to wireless into the future. This decision was supposed to narrow down the exploration of possible technologies and reduce options in the architecture. Hence, it was possible to again focus on technology evaluation, such as BroadR-Reach feasibility.

In early 2016, it was also discussed for the first time whether to use real-time Ethernet variants, such as TSN/AVB introduced for media technology, or authentication or encryption at the Ethernet level. Also, concepts used in Internet technology, such as VLAN, were brought up in the architecture discussions. Bringing up new options or uncertain requirements, such as hard real-time, prevented rapid convergence. These elements just opened up new discussions and increased complexity for decision-making. For instance, whether the industry should go for TSN or not, is a reappearing discussion every year, without any clear decision. Also typical of this era was to set requirements based on available technologies, in order to "prepare easy decisions" later. For instance, whether segment length should be 10, 15, 30, or 40 metres does not come from the industrial application but from the limitations of the technologies on the table.

At this time, it was also not clear how to make connectors between tractor and implement for this new architecture, as the decision on which technology to use was also open. Different discussions with different connector suppliers took place, which tried to answer the question of whether there were existing connectors to be leveraged for this industry, or whether the current ISOBUS IBBC connector could be augmented with new pins/housings, and how to achieve a multi-vendor supply for the new connector. Different ideas from different suppliers and OEMs were presented, but no convergence. However, the direction was clearly towards single-pair twisted Ethernet, known as BroadR-Reach or 100BASE-T1, even though a decision was not yet possible. Also, it was discussed that Ethernet switches may need to have a standardised connector for vehicle diagnostic purposes, but also for expansion purposes. Therefore, the concept around Ethernet was built around the idea of two standardised connectors: an "IBBC-like" connector between tractor and implement; and another for expansion purposes integrated into switches or other ECUs. [5]

At the end of this era, 2014–2017, the main achievement was to agree on how to call the upcoming technology "High Speed ISOBUS", or HSI, but no other clear and written-in-stone decisions were made. However, this period clarified the complexity of decision-making, as the world of Ethernet was versatile with numerous options compared to CAN bus. More questions were raised and discussions opened than consensus or agreements were made.

AEF era 2018-2020 "Search for middleware" and "Hunting connectors"

The second phase of the AEF project team started when Andreas Möller left the position as the project leader. David Smart (John Deere) became the new project leader and reshaped the work. Even if the earlier phase had already worked in subgroups, the ever-increasing number of technical questions were organised into subgroups.

There were two main branches of the work, which became relevant for later stages: progress in the physical layer and progress in protocols. The decision took place in 2018 to go for 1000BASE-T1 technology, which means "Gigabit, single-pair automotive", simplified. This technology was just upcoming, as open-market chips were not available and the number of vendors was limited in general. In addition, two types of the same technology required further investigations. In addition, it was decided that 15 A of 12 V DC should be available with this new physical layer communication, similarly to how classic ISOBUS has available, e.g., in the "in-cab connector". This would allow most ECUs without actuation to operate from the same connector, such as implement-side cameras. This decision was remarkable, as certain existing components on the market provided 4–5 A power capability, but not more. This clear decision was driving the connector and cable design process further. In addition, the number of mating cycles required was clarified from application experiences with the current ISOBUS.

In this era, the goal was to go prototyping-first, in order to find more facts for the comparison.

One impactful decision was to start two prototyping rounds simultaneously: one with industrial automation technology and one with automotive technology. These two branches of possible technologies to be utilised in the agricultural machinery domain had been identified already in 2012, but before 2018, they were only compared on paper, not with prototypes. Whilst industrial factory automation providers had numerous options already back in 2006, as explained above, the automotive technology (passenger cars) had more exclusive options for their industry. As the goal was prototyping-first, it was necessary to decide on one "best on paper" technology from each branch and proceed to prototyping. For industrial automation, the decision was to prototype OPC UA, the latest core technology for Industry 4.0; and SOME/IP for automotive technologies, which was a core part of the AUTOSAR ecosystem. The decision in early 2019 was to leverage some middleware in order to avoid construction of another protocol for Ethernet.

Aalto University (under leadership of the author) took the role in prototyping the OPC UA branch as part of their nationally funded project. They focused on questions like "middleware as a solution for hot plug-and-play" and "process data exchange" similar to ISOBUS Task Controller and basic messages such as tractor and GNSS information. The real-time implementation for resource-limited ECUs was not the first priority, as it was not yet clear at that time which microcontrollers would become common with Gigabit 1000BASE-T1. Middleware should resolve software development aspects such as addressing, service discovery, information modelling, serialisation of data, separation of data model and data exchange, and design patterns like publish/subscribe at the large message level, not at the frame level.

The OPC UA prototype was developed in a PC-to-PC environment by using a standard industrial SDK for both server and client by Aalto University in 2018–2019. The main achievements were to prove that the information modelling capability of OPC UA matched with the core idea of dynamic data structure (DDOP, device descriptor object pool) used in ISOBUS Task Controller, which is the most dynamic part requiring auto-configuration in the current systems. It was also discovered that this middleware conversion allowed bidirectional conversion, which would allow easier transition in task controller functionalities when the logic and algorithms could stay the same and only the backbone for data exchange is changed from CAN/J939 to Ethernet/OPC UA. In addition, they also proved the performance of this technology with various simulations of implement types, such as a sprayer with 800 nozzles (four booms, 200 nozzles in each) or a planter with 400 row units, each having 6 bins with rate control, each with 100 Hz sample time. It was discovered that the industrial automation SDK, without any tuning, allowed a latency of 2–3 ms, even with full configuration. During this development, OPC UA also released their "PubSub" to enable more real-time communication compared to classic OPC UA client-server, but this was never prototyped or evaluated. [6]

In parallel, an ECU and system supplier for automotive carried out another prototype based on SOME/IP. This prototype was also related to Task Controller communication. It was realised with Adaptive AUTOSAR environment runtime in a Raspberry Pi4 computer. AUTOSAR wrapped the actual SOME/IP. The prototype demonstrated the discovery mechanism used in AUTOSAR, realised with SOME/IP for Task Controller. A sprayer was used as a test case, and the client was able to dynamically bind to the server and invoke RPCs and subscribe to events. This prototype used direct access to certain DDIs (device descriptor identifier, defined in ISO 11783-11), without any browsing of the information model, like DDOP. In this prototype, the focus was on SOME/IP, but for the reason of "easier tooling" for the developers, they used AUTOSAR, and the second reason was to stick to common practices in the automotive industry. Whilst this demonstration was a successful proof-of-concept, it also brought up the experience that a simple protocol still requires heavy tooling in practice. Therefore, the project team also addressed in their decision matrix the required tooling and similar aspects for small developers.

Whilst both of the prototypes proved their concept partially, both were incomplete for all mandatory features of, e.g., a full future task controller over a given Ethernet. The OPC UA prototype proved main hot plug-and-play features, such as discovery of dynamic elements, information modelling (standardised for the domain, the so-called companion specification), subscription, high-rate control of actuators and process data subscription, automatic reconnection, et cetera, but it did not demonstrate dynamic addressing, encryption, or embedded hardware realisation [7]. On the other hand, SOME/IP proved DDI setting/getting, dynamic binding to services, service discovery, automatic reconnection, but it did not demonstrate handling dynamic hierarchical data structures, related information modelling, encryption, or embedded hardware beyond Raspberry Pi and its Ethernet. Therefore, comparison between those was only partially possible, and in the short term, neither of those was possible to extend due to limited resources of the parties who had developed them.

The prototypes were still good enough to start a comparison with a decision matrix developed by the team. The decision matrix was filled with consensus-seeking across experts, and developers of prototypes did not attend the process. This decision matrix was ready in late summer 2020, and it was able to rank the candidate technologies starting from number one. For reasons not documented in records, this decision matrix was not implemented. The rationale for disbanding the completed decision matrix is not documented in meeting minutes. The project team later restarted to explore further technologies beyond these two prototypes. This was also the period when there were no further meetings. Obviously, the discussions had moved to other forums, and they did not find consensus to make any decisions or further discuss protocols. This was clearly the end of this era.

However, meanwhile, the physical connector branch had proceeded remarkably. The decision was taken in early 2020 to develop an agriculture-specific connector, and there was a process to select the first manufacturer for this. This breakaway connector was selected in early 2020, and there was clear progress at the end of 2020, and the project team received the first concrete designs by the end of 2020. The year 2020 was a milestone for the breakaway connector design, after several years of exploration. In late 2020, the chairman of the project team also announced his retirement from his company, and this marked the end of this era.

AEF era 2021-2023 "Camera first and tunnelling era" + ISO JWG16 "Horizontal alignment"

A new phase clearly started in 2021 when there were changes in the active team members, but also due to progress with the physical layer. As the protocol and middleware progress was stuck, the new focus shifted to camera systems and "CAN tunnelling". At the same time, AEF also changed their internal organisational structure when it comes to projects and experts. [8]

Camera systems were initiated already more than ten years before, as there was an analogue-first approach and OEMs started to feel pressure to deliver better-quality images for better ergonomics. A few camera suppliers also joined the project team to bring their experience with automotive cameras. It was clear already some years earlier that automotive cameras often use SOME/IP for Ethernet camera streaming configuration (e.g., resolution, frame rate, zoom, etc.), whilst actual streaming uses other common Internet technologies. Perhaps this was confusing the experts, to see some synergies around SOME/IP, even if eventually it was discovered by the team that it was just a rough umbrella and each manufacturer had their own non-harmonised realisations. [9]

CAN tunnelling was nothing new. This was already proven conceptually in the John Deere & Rauch project in 2007–2010. However, it was omitted for several years, as the decision in early 2015 was to move forward with "dual stack" and not with tunnelling. However, as decision-making around middleware-based protocols was not possible, it was likely easier for the management to continue with something, which was simpler and more realistic to finalise in the short term. This industry was able to make a short-term solution already in 1986–1987, when the DIN signal connector was standardised under DIN 9684-1 – hence it makes sense to make something ready fast and deliver to the market.

The other new beginning was the collaboration with other domains to achieve horizontal alignment across agricultural, forestry, mining, construction, earth-moving machinery, and even the on-road truck industry. The main driver was to agree on a joint physical layer in order to increase the demand for annual manufacturing of required components, which now were quite specific due to earlier decisions (domain-specific breakaway connector, using 1000BASE-T1, which was exclusive to automotive, chips, cables, et cetera). If all aforementioned industries were able to agree on the same connector, cabling, transceivers, etc., the need for annual production volumes would be more significant and would attract more suppliers to the market. Later, the same goal was also seen in software stacks, like middleware, diagnostics, and even camera interfaces. However, the joint working group does not aim at harmonising everything but trying to understand what elements of future communication "faster than CAN" could be harmonised across all industry domains, which could be harmonised within each industry domain, and which are proprietary. This horizontal alignment group had organised under ISO TC127/SC3/JWG16. Even if ISO JWG16 was founded a bit earlier, the actual work started when the AEF project team and their experts brought to the table all discussions and experiences which had been accumulated since 2012. This boosted the work of ISO JWG16 and especially motivated the on-road truck industry and earth-moving industries to share their experiences. [9]

Due to discussions in ISO JWG16, the agricultural industry wanted to take another look at middleware options and protocols for a long-term solution (whilst CAN tunnelling was considered as a short-term solution). Another middleware was brought to the table in early 2023, which was called DDS. Whilst this option was already on the table during 2017–2018 discussions, now it was driven by its increasing popularity and the holistic idea to cover communication also to the management layer of processes.

In late 2023–mid-2024, Technical University of Munich (under leadership of the author) realised another proof-of-concept at the request of AEF. The scope was the same as earlier OPC UA: mainly focus on dynamic data, information modelling capabilities, and main hot plug-and-play capabilities of DDS in the context of the future Task Controller. This work was delivered in summer 2024 for the project team decision-making. Once again, the proof-of-concept delivered concrete results when it comes to opportunities and limitations of the middleware, but again this did not help to find a breakthrough in consensus. The situation was very similar to the events four years earlier.

A new tool was introduced in this era for High Speed ISOBUS development: a plugfest. The idea was to start plugfest activities along with other ISOBUS plugfest days on a separate room or table, even if there was not yet any standard, to play around and get experience with testing cross-manufacturer partial prototypes. The same approach was used with LBS, with the first plugfest at Groß-Umstadt in 1993, or with ISOBUS, the first plugfest in Wageningen in 2001 [1]. This was the next level of prototyping, but the focus was not been in testing the details of different prototypes trying to comply with the specification draft, but just to get feeling for concepts and demonstrate ideas. For instance, in 2024 plugfest, up to four different CAN tunnelling concepts were demonstrated. Plugfest partial tests have been beneficial to learn about simple aspects, such as discovery of services, addressing of IP networks, and long-cable packet losses – beyond the meeting discussions.

Whilst writing this in the last days of 2025, it is not possible yet to conclude the milestones achieved by ISO JWG16. Main milestones and relevant decisions taken can be observed only a few years afterwards, when one step has led to another. Currently, ongoing discussions might be relevant or not relevant, but at least for the physical layer, decisions are more written in stone.

Final remarks

It was at the latest around 2011 when the agricultural machinery industry and its electronics experts shared the common need for "beyond CAN" technology for future agricultural vehicles. The first steps followed the stepping stones of the early 1990s when CAN bus first came to the tractor internal bus and later to the open tractor-implement bus, as, for instance, the John Deere 6210RE introduced in 2011 used EtherCAT. This time, standardisation of the tractor-implement communication system seems to be much harder for various reasons; at least the era 2012–2025 spans 14 years, which is already longer than the period 1991–2003 when the current ISOBUS was cooked.

Meanwhile, some companies have started to deliver to the market proprietary communication systems between tractor and implement, which partially leverage achievements mentioned in this article. This is a natural evolution – when the common standardisation process is stuck, then the train must move on. A standard is required to match with requirements of mixed-fleet farmers.

Author's note

The author has served as a member of ISO TC23/SC19/WG1 from 2006, was a member of ISO Task Force 2012-2013, and has been a member of AEF High Speed ISOBUS project team from 2016, and participated directly in many of the events described herein. Where cited sources are not available, statements and observations are based on the author's meeting notes, committee participation, and direct experience.

Literature

 [1]    T. Oksanen and H. Auernhammer, ISOBUS – The Open Hard-Wired Network Standard for Tractor-Implement Communication, 1987–2020., ASABE Agricultural Equipment Technology Conference (AETC), Louisville, KY, Paper 913C0121., 2021.

[2]     S. Marzani, C. Fantuzzi, M. Ferretti and A. Pavesi, FlexRay and ISOBUS Integration for Off-Road Vehicles: New Standards Together for Safety and Effective Applications, SAE World Congress Technical Paper 2006-01-1054. SAE International. , 2006.

[3]     O. Peters, P. Pickel and N. Tarasinski, Real time Ethernet for Tractor Implement Communication., 68. International Conference LAND.TECHNIK/Agricultural Engineering of VDI-MEG Agrartechnik and Society of European Agricultural Engineers (EurAgEng), Oct. 27th -28th 2010, Braunschweig, VDI Verlag Düsseldorf, 2010, ISBN 978-3-18-092111-2, pages 285-292., 2010.

[4]     P. Pickel, Electricity for tractors and tractor-implement systems., In the proceedings of the 29th Club of Bologna meeting., 2019.

[5]     D. Smart and V. Brill, High Speed ISOBUS, an AEF Project for Next Generation Ag Networking., Land.Technik AgEng 2019 (VDI-Berichte Nr. 2361, pp. 91–106). VDI Verlag., 2019.

[6]     M. Siponen, I. Seilonen, S. Brodie and T. Oksanen, Next Generation Task Controller for Agricultural Machinery Using OPC Unified Architecture., Computers and Electronics in Agriculture, 203, 107475. , 2022.

[7]     M. Siponen, I. Seilonen and T. Oksanen, Modelling and Simulation of Tractor-Implement Automation using OPC Unified Architecture for Next Generation ISOBUS., Aalto University, Aaltodoc SCIENCE+TECHNOLOGY series: Working papers. ISBN 978-952-60-8935-5. 45 p. , 2020.

[8]     S. Brodie, T. Oksanen and A. H. , Buzzword ISOBUS., Informatik‐Spektrum, 46(1), 46–50., 2023.

[9]     D. Smart and V. Brill, AEF – High Speed ISOBUS – Technology Readiness for a Next Generation Network., Land.Technik AgEng 2022 (VDI-Berichte Nr. 2395, pp. 551–558). VDI Verlag., 2022. 

Author data

Prof. Dr. Timo Oksanen is the head of Professur f. Agrarmechatronik at Technical University of Munich (TUM), since 2019. He is also Visiting Professor at Aalto University (Finland), School of Electrical Engineering.