Maybe? I'm speculating here as it's not my field. The obvious explanation to me is very different to the obvious explanation to every other comment I've seen so far. That difference seemed interesting enough to be worth posting.
The question of where liability falls after a repair isn't covered in the articles linked unfortunately. It seems plausible that it was initially whoever wrote the software and is now someone else.
I think it's extremely likely that this disable-train-on-various-conditions behaviour is exactly as specified and documented since train software is a bit obsessed with formal methods and documentation. It's then only "silent sabotage" to the extent that said docs were ignored.
It's credible that a way to easily disable these safety checks for the case where it's now someone else's liability wasn't considered worth paying for by whoever bought the train. It's tomorrow's problem after all. Also the customer may not be totally convinced of the necessity of the software dev paranoia, especially if they're not liable for failures.
So sure, maybe this is evil/negligent software people at the train company. I don't see that conclusion well supported by the article.
Your argument is based on an incorrect understanding of liability, and is also nullified by the fact that these measures, allegedly justified on safety grounds, were not just undocumented (see other sources) but clearly deliberately hidden, to the point where the manufacturer pretended not to know why the trains would not start.
Update: here's a quote from the Ars Tech. article itself, showing a) no tampering with the trains' software or hardware was necessary to get them running, and b) there's no even slightly plausible case for believing the manufacturer was unaware of this. Furthermore, if it really was somehow unaware of what was going on, then these 'features' cannot be justified as a safety measure.
Dragon Sector got the trains running after discovering "an undocumented ‘unlock code’ which you could enter from the train driver’s panel which magically fixed the issue."
Update 2: It is barely plausible that the ability to track the trains' presence in other maintenance shops was initially added to gather evidence for liability and warranty purposes, and then someone had the dumb idea of using this to covertly disable trains when this happened.
Note that the use of a third-party maintenance operation was not a secret: the train operator solicited bids for the work, and the manufacturer tendered one. Clearly, third-party maintenance was not in violation of any contract (and if somehow it was, the manufacturer did not need to gather any covertly-acquired evidence for a breach-of-contract suit.)
>It's then only "silent sabotage" to the extent that said docs were ignored.
From what I've read, the maintenance company did scour all documentation and found no explanation for why the train was disabled. It was an entirely undocumented feature. Maybe they were just lying, but this idea you have in your head that it was just a fly-by-night operation who couldn't be bothered to read the documentation is contradicted by the available public record.
So all of this obviously biased and incorrect speculation on your part is based on.... not being an expert in the field... and not having read the actual article? Thanks man, very insightful.
The question of where liability falls after a repair isn't covered in the articles linked unfortunately. It seems plausible that it was initially whoever wrote the software and is now someone else.
I think it's extremely likely that this disable-train-on-various-conditions behaviour is exactly as specified and documented since train software is a bit obsessed with formal methods and documentation. It's then only "silent sabotage" to the extent that said docs were ignored.
It's credible that a way to easily disable these safety checks for the case where it's now someone else's liability wasn't considered worth paying for by whoever bought the train. It's tomorrow's problem after all. Also the customer may not be totally convinced of the necessity of the software dev paranoia, especially if they're not liable for failures.
So sure, maybe this is evil/negligent software people at the train company. I don't see that conclusion well supported by the article.