I work on automotive software (not Tesla), and it's like this partially because it makes development _way easier_. Rather than needing to get a whole car to the dev team, you just give them the specific part that they're working on. Anything that needs outside features usually just fails gracefully (e.g. no speedometer or no location for maps). These are usually mocked for testing, or you add the specific ECU that provides it for your testing setup if needed.
replyModern cars have tens of ECUs, so if you had to have all of them for testing, that would get unwieldy extremely quickly. Not to mention that cars are pretty resilient to having random parts failing, you don't want to lose the entire dashboard just because the ECU that provides camera data failed, or something.
I work on that software too (again not Tesla). One other thing - often the hardware we get is per-production and has a list of errata that will be fixed before production. They don't want to make too many of these for engineers because it is done in a fast turn-around higher cost factory and it is expected that once in a while things won't work at all (someone forgets to connect power to the CPU pin or something similarly stupid that requires a lot of manual wiring to fix on each one). As such you have to justify getting any controller and often share. Once the product is shipping they make many of them and it isn't a big deal to get one on your desk - but you have now moved onto the next thing and so the problem returns.
replyYeah, I expected some gigantic writeup about tricking it into thinking all other systems are connected to it but maybe it's made this way so it's easier to repair without needing the whole car
reply