Our previous article examined the evolution of implement controls alongside tractor technology. By the 2000s, tractors were controlled by PLCs networked via CAN bus, and the ISOBUS standard was established to create uniform communication between tractors and implements across brands and to allow seamless integration into the tractor controls interface. The appearance of an interactive digital screen in the tractor also created the possibility of using software to overcome limitations of physical controls, making tractor controls capable of controlling more complicated implements and eliminating the need for separate controls and displays for the implement. Sounds great, right?

A quick survey of farm equipment shows mixed tractor/implement integration though. Why is this? Here are some reasons.

Proprietary tractor OEM displays, controls, and associated software. This causes several headaches for the implement OEM. First, they must develop and maintain unique implementations for each tractor OEM which substantially increases cost and complexity. Second, tractor technology (both hardware and software) has significantly lagged behind consumer hardware and software capabilities found in tablets and smartphones, limiting development options and flexibility. Related to this is also a relatively poor user experience in the tractor vs. what we’ve come to expect from our smart devices. This is a function of both better software and hardware.

Inconsistent following of ISOBUS standards. If I want my implement to refer to tractor ground speed as calculated by the tractor’s existing sensors, ISOBUS says that message should be in a standard format on the CAN bus, regardless of brand. Well it isn’t, and it may not even be consistent between the models/years inside the same brand.

The alternative to tractor integration is developing and maintaining a completely independent controls interface that works consistently regardless of what tractor the implement is connected to. Next time, we’ll explore some of the tradeoffs with this approach and how emerging AI-enhanced automation plays into this.

By Chris Hunsaker, Co- Founder / CEO at Acuitus Ag and guest panelist at the 2023 Marketing & Distribution Convention.

This article continues a series where we’ll explore different aspects of technology and how they might shape the future of ag machinery.

In the 1960s, while Gordon Moore was advancing semiconductors, another development was taking place in industry. For decades, factory machines had been controlled via electromechanical relays (mechanical linkages, buttons, switches, coils, and lots of wire). This system became complicated as machines became more sophisticated. All logic in how the relays interacted with each other had to be built into the actual wiring and hardware of the system (called ladder logic). Any change in the behavior of a particular system required it to be rewired. The more complex the system, the harder it was to service, too.

In 1968, General Motors began work on a relay system replacement in their factories using a simple computer to mimic the ladder logic of the physical system with software. By 1969 (ironically the same year the $200,000 Apollo Guidance Computer put man on the moon), the Programmable Logic Controller (PLC) was born and GM started using them in manufacturing. PLC compute power was limited, but this wasn’t a problem because they performed simple tasks.

PLCs first appeared in automobiles in the 1970s, first to control the engine and then to control other functions. The approach was the same–replace physical control systems with computers to mimic physical system functions. Simple PLCs required simple software. Proprietary PLC software was created by PLC manufacturers focused on the reliability, security, and safety of the system. In off-highway vehicles (like construction, mining, and agriculture), use of PLCs followed trends from industry and automotive, with much of the hardware and related software being adapted from those applications.

As use of PLCs in vehicles grew, so did the need for a communication protocol standard for data transfer between PLCs. In the mid 1980s, Bosch engineers in Germany created the Controller Area Network bus (CAN bus) to standardize and simplify communication between PLCs in automobiles. The protocol was swiftly adopted in automotive applications because it was robust, handled real-time data transfer reliably, and reduced the amount of wiring needed to connect different vehicle systems.

CAN Bus use began in agriculture in the 1990s, first on tractors and then on implements via the ISO 11783 standard. The ag-specific implementation, dubbed ISOBUS, envisioned integrated tractors and implements. Twenty five years later, much of that vision remains unrealized. In the next article, we’ll explore why.

Come see me in Little Rock at the Supplier Showcase at booth # 39 or reach out at either chris@acuitusag.com or (208)243-0135!

| Member since 2023