The problem I highlighted, although a seemingly minor one, is actually a symptom of a problem within the automotive industry and their attempts to solve problems around complexity. Even minor things are not locked down, what endianess is used? Why not allow both, What CRC is used? Don't specify, allow some random engineer to decide! Let's make things "generic", because making things generic is good right?

Instead you could specify "This is an X ECU, all X ECUs have the following messages, each message has these signals, we use this CRC, we use this endianess, this is how we handle errors, etcetera". Instead if you get an brake ECU from one vendor or another, they have completely different interfaces and behaviors around error handling. This is just one facet of the software engineering problems in the automotive industry.

It is as if they do not know that other software projects exist. Take for example Linux, they use it but they do not understand it. Here we have something that has been ported to a dozen different CPU architecture, targets god knows many different systems, and can be configured with thousands of different drivers. It works, and it might not be appropriate for a safety critical system, but you can learn by how it does things, what its build system looks like, and so on.

The re-usability that has actually worked is done by reusing Operating Systems, Programming Languages, Libraries / Modules at language ecosystem level, and at a more fine level Objects / Interfaces / Generics. It is also done by locking down the behavior of systems and standardizing them, either by an external body, or preferably by a standard that has won out in the market by virtue of being better. It is not done by making a standard in which everything can happen, nothing is actually agreed upon, and oh, by the way you have to use these incredibly expensive code generation tools that just don't work correctly.