Ultimately it's a price control strategy to pit these suppliers against each other to lower costs. But it means that designing these electronic sub-systems isn't just a question of the design itself, but also of managing all of these supplier relationships as well, they all have different contracts, you would have to coordinate all of them at once to make sure things are interoperable, etc.
Apparently that rabbit hole goes super deep in which the large auto manufacturers in the US throw their weight around and force suppliers into selling parts at cost or with razor thin profit margins. And on top of that, they force the suppliers to eat the loss when it comes to cyclical business demand (e.g. storage costs for over-producing during low demand and increased labor costs during times to under producing from high demand)
On paper Mexico reaped enormous gains from NAFTA(/MCA) but those went to a small slice of the population, and people on fixed incomes/not in manufacturing/services objectively got worse due to inflation and rising cost-of-living, property prices. The share of GDP effectively lost due to corruption is also an issue.
i'm sure that every time this happens, it individually makes sense to do it at the time.
This is a microcosm of how large systems get developed in small pieces, by different people, over a long(-ish) period of time. It's the same in the software world too i think, but presumably has a lot more consolidation than cars (as software for cars might be less common, and thus employees moving between companies is unlikely to make any sort of cross-pollination like there would be for FAANG-like companies).
> We actually spent considerable amount of time just developing our own custom protocol
Not only is this unintentionally hilarious, it’s a real life example of an xkcd comic (https://xkcd.com/927/) that will never cease to be true.
> eventually all our data communication would use a single unified protocol from micro-controller to IoT Linux to cloud data-ingestion pipeline to database.
This, however, is remarkably impressive, that you were able to build a single protocol that fit this end to end use case.
On the other hand it was nice being able to just import a library into your code and JUST SEND A FREAKING MESSAGE without having to deal with thousands of lines of code that were last changed 3 years ago and nobody knows how it works. The scrutiny on the code quality of the common protocol was much higher and therefor much more pleasant to use and troubleshoot.
All the encoders and decoders of messages used the same code in all the parts of the stack (technically 2 implementations, one in Go and one in C)
When you have dozens of communication lines required between different parts of the system it becomes just as complicated as your average micro-service cloud. Really, a car is a distributed system with dozens of "services". An analogy is that each microcontroller-microcontroller communication use their own custom binary-encoding API that runs on multiple different, incompatible versions of HTTP.
We actually spent considerable amount of time just developing our own custom protocol for communication that could run on all sorts of different physical interfaces (CAN, ethernet, modbus, etc) as well as a series of proxies between devices (so component A can talk to component C through a proxy in component B). And if we had to use a custom protocol from an external manufacturer we had to wrap it into our own custom protocol.
That protocol was actually used for our cloud data reporting as well, so eventually all our data communication would use a single unified protocol from micro-controller to IoT Linux to cloud data-ingestion pipeline to database.