And in principle, there is *no* point at which the developer genuinely has to give up. They can fake a working implementation forever.
-
-
Replying to @qntm
If the tester and the developer are not on the same side, it is VERY difficult for the tester to force out the implementation they want
1 reply 1 retweet 2 likes -
Replying to @qntm
This is at the unit test case level. At higher levels, fakery becomes harder, but is still possible if the developer is motivated
1 reply 0 retweets 1 like -
Replying to @qntm
The crucial point is this: it needs to be impossible to computationally distinguish an emissions test from regular driving
1 reply 2 retweets 2 likes -
Replying to @qntm
If an engine passes your test, and later you wish it hadn't, harden your test. The engine manufacturer is not on your side
1 reply 0 retweets 2 likes -
Replying to @qntm
Here's the critical diagram. Coloured lines change VW engine behaviour if crossed. White line = emissions test http://lwn.net/Articles/670604/ …
1 reply 1 retweet 2 likes -
Replying to @qntm
The coloured lines are fixed features of the ECU program. An emissions test just happens to always pass down that narrow channel
1 reply 0 retweets 0 likes -
-
Replying to @qntm
Of course, having a test which is unpredictable and undetectable is somewhat antithetical to having a test which is standard across engines
1 reply 0 retweets 1 like -
Replying to @qntm
Now imagine a scenario where the ECU dev AND the tester are in cahoots. The "random" emissions test profile encodes a signal to the ECU
1 reply 0 retweets 1 like
The pattern of "roads" driven down spells out "T-H-I-S-I-S-A-N-E-M-I-S-S-I-O-N-S-T-E-S-T", telling the ECU to go into low-emissions mode
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.