Taking a break from the rigors of round-robin compatibility testing at the Agricultural Electronics Foundation (AEF) Plugfest in Lincoln, Neb., this spring (also referred to fondly as “speed dating for ag nerds” by one attendee), AGCO software engineer Mike Schmidt and Dave Smart, staff systems engineer for John Deere and team leader for AEF’s high-speed ISOBUS Project, discussed the progression of compatibility over the years through AEF conformance testing, the simplification of equipment connectivity for farmers of all brands and expectations for ag functionality with high-speed ISOBUS network capabilities on the horizon.

Dave Smart: When it comes to working together at Plugfest with competitors in the market, the line in the sand is how we make the customer successful. Farmers don’t always buy one brand of equipment. For many systems, they’re blended systems and may not work perfectly. We of course wish they would. When those challenges related to ISOBUS filter their way back into engineering, it’s often one of the people in this room that’s involved with sorting out the problems. We work together to understand it and figure out, ‘This time it’s ours, that time it’s yours, let’s figure out how to again correct it and make it successful for the customer.’

During the early stages of USB on computers, you could plug in a printer and your mouse stopped working, or you plugged in a camera and something else, the keyboard stopped working. Ten years ago, ISOBUS was fragile in that same way. Plugfest serves as a key opportunity to solving that. I’ve run into issues where virtual terminal (VT) technology is used, but a product isn’t marketed and ISO compliant, resulting in customers putting two things together that almost work, but not quite. That was from a couple of years ago when I’d run into those issues, but in the last year I don’t recall any.

Mike Schmidt: Agreed. And establishing more clarity in the standards certainly helped that progression. Developers always interpret standards a little bit differently, so finding and resolving those differences to write them more clearly is crucial. AEF Conformance Testing helps with that too. The people writing the AEF Conformance Tests have already talked with the original authors to understand the intention and how it’s supposed to work, which helps to clear up those misunderstandings or multiple meanings of the spec.

Nowadays, it’s not too often you have to worry about VT issues. The bigger issues today center on task controllers, which is a much newer spec than the VT written by some of the same authors, but a different group of people as a whole. It’s a lot more difficult to solve those problems, and we’re still working on fully defining it and cleaning up the multiple interpretations of things.

Smart: If you go back in time before ISOBUS, we had implements that came with a big harness, cable, display and some buttons. For that implement, you basically wired it into the tractor, used it and it was dedicated. Then the next implement comes with its own cables and harnesses so forth. How much automation can you get by taking that system and evolving it forward? Every company, in theory, could have their own 100% proprietary automation based on displays, push buttons and so forth. But does that make sense?

From a customer perspective, commonality is reflected through everyone having 3-point hitches and hydraulic connectors, and there are standards that govern those things. So now with ISOBUS, we’ve got that standard for data as well, which makes it easier to grow into levels of automation with task controllers, controller description and data analysis to make a new plan for the next year.

Schmidt: I’ve got a picture of a cab on my desk in my office and it’s got a dozen different terminals that are mounted in the cab. You can barely see out the windows of the cab. The farmer had so many different things he needed in the cab all at once just to run everything that he had connected to it. Everything had its own terminal. But with ISOBUS, it’s plug-n-play agriculture. Plug your implement into your tractor and it works. We’ve gotten quite a ways down that path.

Smart: The first Plugfest was in 2001. Since then, the level of automation has improved, though expectation has paced along as well. In some cases, expectations have outpaced our ability to actually attain success in our operability, but we divide and conquer problems. Some of our tool providers have experience working in the automotive type industry, and they’ve said there is nothing like this in other industries where the competitors are such close colleagues.

Schmidt: Some of these guys were at my wedding. We’ve worked together a long time. The end goal for all of us is still the customer and making sure we give them the best experience. Even if it’s a John Deere tractor pulling my implement, I want it to work the best that it can. Of course, if he’s pulling his AGCO implement with his AGCO tractor, we might be able to provide some extra features, but I want the user interface and interaction between them to be seamless so that we’re not getting calls about why it doesn’t work. It should just work together, according to the standard. Farmers want more automation and not so many manual steps. Making fewer support calls and being able to troubleshoot from the field or know that a technician is on the way is a big deal for them.

Going off your work with AEF what’s the next big avenue in equipment compatibility?

Smart: The speed of CAN-based ISOBUS is very slow. It’s not unlike the dial-up modem from many years ago in the terms of performance and no longer adequate in anybody’s home. Being on the AEF project team for high-speed ISOBUS, we’re pursuing a network to provide more capability from an infrastructure perspective. Many of the operations would still be the same regarding applied prescriptions and data logging, but now instead of a planter delivering 32,000 seeds per acre when the set point is actually 31,500, we’ll have the bandwidth to get down to row-level and identify what each row is doing.

From there, we can determine the need for a prescription that can adjust row-by-row. With the bandwidth of CAN, that’s basically not practical. It’s just too constraining. You can’t get the information you would need across the network timely enough for the prescription that would like to have.

You’ll get larger amounts of bandwidth with high-speed ISOBUS, and you can take advantage of the extra precision both in control and the data coming from the machine. Now I can use analytics to create another control to reduce chemical application and save money. We’ve got a ways to go yet with development, but it’s the same type of application as the universal terminal, task controller, automation sequence controller or GPS based guidance, just more precise. And it won’t make everything obsolete. Part of our strategy is to provide a continuum from existing CAN-based ISOBUS toward the high-speed version.

Schmidt: What impact will high-speed ISOBUS have on machine-to-machine communication?

Smart: Most companies already have some level of communication using proprietary means between their equipment and wireless points, but there’s work being done by another AEF project team to improve wireless in-field communication, specifically the standardization of data when matching up grain equipment with combines from different companies during the offloading process. There’s scenarios where CAN wireless to CAN machine connectivity works, but there’s many other cases where bandwidth is a problem and the high-speed ISOBUS will be needed.

In-cab cameras and monitors will also become more compatible with high-speed ISOBUS. Similar to implements, where everything was its own standalone system of original wires and cables for decades, the new network will allow farmers to easily integrate cameras into the implement for real-time viewing of what’s happening on the machine. It’ll reduce the cost of cables and connectors while alleviating the complexity of all these extra systems piling on top of the other.

PFD Summer 2018 Contents