Farmers Fight John Deere over Who Gets to Fix an $800k Tractor

A big part of this is the result of manufacturers trying to protect the profits of themselves and their dealer networks.

Dealer network profit is increasingly reliant and dependent on service income.

So attempts to lock in serviceability are to be expected.

I wonder if manufacturers will consider and experiment with a platform approach?

Perhaps along the lines of Salesforce, Xero, Apple App Store.

And take a cut of the ecosystem income.

HN previously on tractor DRM:

1 day ago: https://news.ycombinator.com/item?id=22482598

2 years ago: https://news.ycombinator.com/item?id=13925994

A big part of this is the complexity of the project. There are a dozen sensitive control systems in a modern tractor, working in concert. An operating tractor is several tons of steel with dozens of large sharp blades whirling and cutting. Do something wrong and, unlike a Tesla which might crash and kill you, these things can take out an elementary school.

possibly a market for replacing this software with open source versions?

The primary drivers of the locking down of software capabilities of tractors came down to emissions, if I recall correctly. Manufacturers are told their Ag equipment must reach certain goals in terms of output of waste gases which requires rather tight control of the combustion process. The issue I see though, is that upon being given that inch of latitude, Deere took a mile by using that as a likely excuse to enforce things in software like DRM that gimps the power output of the engine without paying a premium fee. Figure out a way to get the same results with Free, open source software, and generally speaking most problems will go away as long as you're willing to actually operate the thing and not relying on their drive-by-GPS software to do the work for you.

While tractors are undeniably complex mechanical devices, and always have been, it's only with the addition of proprietary software in the current rent-seeking happy buisness environment that these anti-user practices have become possible. Break the dependence on the software, and you should be good to go.

Though that "break the dependence" is doing a lot of heavy lifting there. Control software is no joke; but if anywhere would be the place to start hacking an open-replacement together, at equipment would be the place to start. Low speed, the operator is safely ensconced away from the whirly bits, and most importantly, low machine density.

If I had a tractor no one else was using; heck, I might just have basically tried to create the statechart and kludge together something that'd end up working.

Off the top of my head the project would require

A)breakdown of the PCB's of the ECU/BCU/ACU(Engine/Body/Accessory Control Units). These are assumed parts, I haven't seen a block diagram; but the gist is, if there is a PCB, a schematic will need to be inferred from it. You don't need to downright copy it, but you do need to make sure you account for every sensor. Emissions controls are no joke.

B) Experimentally, or through consultation of regulations, figure out the targets Deere has to hit to meet with regulations. You already know the engine and emission system itself is capable of hitting it, you just need to derive the parameters. A dyno and somebody experienced in the art of ECU tuning and some experimentation with different mappings should eventually find you converging on Deere's settings.

C)Analyze all signalling between components. This is where things get tricky. If it's just in the clear CAN bus style, you can tap the lines to build up your statecharts. If they've gone and thrown a bunch of encryption/obfuscation into the mix, and there's no way to trivially extract the keys from the hardware, you at least get an idea of what patterning is present, which can be enough to at least give you a sense of direction to follow.

One'd best set their goals on replacing the ECU firmware first and foremost, but I'm guessing there's probably some dependence of the control unit for the accessories on seeing a John Deere(TM) ECU that'll quickly cascade the scope. I couldn't imagine so many getting irritated by this otherwise.

I wouldn't be out or willing to replicate their auto-GPS drive features. Those are innovative enough I'm willing to leave them with a pass on it. The fundamental operation/repair of the tractor being locked out though is beyond justifiable. It'd be a multi-year endeavor for someone alone assuming enough funding to keep them chugging along with working on the project as a day job as a computer scientist with a rather Jack-of-all-Trades approach; throw in a competent EE and ME, and you might get something sooner. The scope would initially only cover a single tractor type, but once the process has been refined, it could be expanded to other models given that once you find something that works, you tend to stick with it.

All of this would of course carry an absurdly high risk of being sued most likely. They'd make the argument we're trying to copy their design. One'd have to know a skilled enough lawyer to be able to navigate the morass to ensure it was clear in court that all that was going on would be an independent reformulation of software that meets the same physical output parameters that just happens to line up with John Deere's tractors. Similar to how GNU Octave is a functional clone of MATLAB.