What is your point? I have a relative that lost his arm to a combine. There was no lawsuit, he did not seek damages. Farmers are well aware of how dangerous this equipment is.
The point is I don't think allowing the modification of software in what is essentially a factory on wheels is a safe thing to do.
When we bought our '81 Ford there was a ton of bodge jobs and half-assed repairs(that helped us talk down the price) that I could easily verify by visual inspection. I knew because I could see them that they weren't inherently dangerous. Software doesn't have the same analogy in this space.
> The point is I don't think allowing the modification of software in what is essentially a factory on wheels is a safe thing to do.
Someone has to do it. What makes John Deere's embedded software engineers more qualified to write software for a factory on wheels than the embedded software engineers working directly for the farms?
Especially when we can't even check the former group's work.
"Someone has to do it. What makes John Deere's embedded software engineers more qualified..."
Simple, John Deere, probably like us, has spent more testing the software than you could ever do on your own.
You can't judge complex software just by looking at it. It must be tested. People who fail to understand this wind up making these uneducated comments. Go study ISO26262 and the MTB calculations required to pass it and maybe you'll change your tune.
Tested software runs on real vehicles and simulators at large companies, as I stated, running into the multi-million dollar price range. There is zero amount of code inspection the general public can do that would give the same assurances you get through testing.
Bottom line: just looking at code is not enough. You must test it. This is unit tests, simulations, field tests, harsh temperature, vibration, power cycle, high side/low side power distribution, code coverage, etc... None of this is possible by you inspecting code.
> I knew because I could see them that they weren't inherently dangerous. Software doesn't have the same analogy in this space.
This has a lot more to do with manufacturers unethical approach to closed and obfuscated opaque software than any inherent problem or limitation of the field.
You were able to recognize the problems or lack thereof for your car because a) you could actually see it, and b) you have more than passing familiarity with how cars work. There's no reason both of those can't be true for the vehicle firmware as well.
perhaps, but if you sold the equipment without telling the new owner they were running your code and they got hurt or killed, as I said above, companies don't want tie up their resources fighting these claims or dealing with it in the first place.
there is the doctrine of an 'attractive nuisance' [0] though, which gives precedent for making owners liable for damages caused to third parties by some dangerous object they did not sufficiently prevent access to... that easily hackable by the user marketing checkbox, combined with a sharp and pointy heavy agricultural spinning tool of death might count?
That seems to apply to children.... I mean you should add some safeguards, to prevent the code from being modified by children messing around, but I dont think this would apply to an adult farmer trying to modify his tractor.
When we bought our '81 Ford there was a ton of bodge jobs and half-assed repairs(that helped us talk down the price) that I could easily verify by visual inspection. I knew because I could see them that they weren't inherently dangerous. Software doesn't have the same analogy in this space.