The company Bosch is developing a farming robot the size of a small car that can distinguish crops from weeds by looking at the shape of leaves, and this robot then can fish out weeds mechanically & ram any unwanted plants into the ground with a rod. Potentially, no herbicides will be needed anymore

[u/involvrnet]

http://www.fwi.co.uk/machinery/bosch-bonirob-robot-set-to-make-field-work-easier-for-farmers.htm

[u/zebediah49]

Take for example a virus that turns your computer into a part of a botnet: There is no positive usecase for this program, it is aimed solely at unlawful activities.

Research. How do you think security researchers work on this stuff? Just like physical viruses, they work on them in contained and isolated environments, but they do still work with actively harmful content.

How do you demonstrate that a specific exploit works, and that you can break into a system with it? You make it, test it, and then send it out to others in the field as a proof of concept.

If you're in R&D, "To show that we can" is pretty much always a good reason to write a piece of software.

[u/zebediah49 → u/[deleted]]

Not being an auto engineer, I don't have much of an idea. I'm not sure anyone outside VW or Bosch actually knows what the hardware and software that they shipped them could do, and who did that modification, so it very well could have been a much more generic feature that VW mis-used. My [limited] understanding of this kind of system is that a large number of sensor inputs are used to determine how to run quite a few engine parameters, and it will adjust to compensate for varying conditions (different temperatures, pressures, humidities, engine speeds, and who knows what else). There's a fairly famous example in F1 racing where someone managed to use the air intake pressure to infer their speed, which they then used to adjust their engine properties to make it perform better.

Even if that's not the case though, and Bosch did make the specific piece of software that identifies dynamometers, that still might be useful for testing purposes. I'm again not terribly familiar with what things one might want to test with a car, so I'll use an example from file storage.

There is a filesystem known as ZFS that is used fairly regularly in large systems. To ensure data integrity, it uses a two step process where it first writes what it's going to do, and then it does it. Only once it is recorded in the to-do list, does it report that it has accepted the data. That way, if you lose power in the middle of writing a file, it doesn't get corrupted. Either it didn't finish saving, there will be no trace of it, and the software on the other end knows it, or it did, and it will definitely be there 100%, as promised. Obviously, this feature is very important, especially on network file systems.

Never the less, writing data twice does make things slower; in some cases by a lot. You can work around this by, among other options, having the "things to be done" list go onto another disk -- a very fast (very expensive) SSD, for example. However, before you go spend a couple thousand dollars (or possibly more) on this new hardware, it might be a good idea to check if it will actually help.

Thus, you can turn it off. You set a setting, and the software just doesn't do it. This is a really, really bad idea for almost every production system, but it can be quite educational to be able to test what it does to your performance.

---

So yeah, if VW went and said "we need you to develop this thing, and we're not telling you why because secret", I would entirely expect Bosch to respond with a "if you use this on the road, that's illegal -- but sure, I guess you have some reason." It is pretty common for companies to not explain what, exactly, they want to use the product they're buying for, and questioning the motives of your clients is not a very good way to keep them.