"AUTOSAR is a good idea, it works in theory", nope, much like communism if your theory does not work and continues to fall flat on its face it is a terrible theory. No one would say a theory of gravity that predicted you would turn into a unicorn if your really wanted to and dropped a ball at the same time had merits.
Here is an idea to make the automotive industry slightly better, just an incremental improvement. DBC files are used to specify CAN interfaces, they allow big endian and little endian messages within THE SAME MESSAGE, which is madness. Why not pick an endianess, just one, it does not matter which, do not make things generic (I have nightmares of German mechanical engineers writing software saying the word "generic"). Do that an you have actually achieved something. I am not even suggesting specifying what messages numbers do what, or what signals they contain for a particular ECU (which would make literal components reusable). The automotive industry is riddled with bad, terrible, software.
I do not know how you blame consultants, the German automotive industry sabotaged themselves.
I have no idea how it can be used in safety critical software, because no one understands it. I guess they just test the fuck out of it.
Sorry for the poorly thought out rant...AUTOSAR makes me...emotional.
I agree with your point about incremental improvements. And I agree that reducing useless options would improve the status quo.
I will have to take your word on seeing projects worse than AUTOSAR ones, I have seen terrible non-AUTOSAR projects, but the only good projects I have ever seen in the automotive industry have been non-AUTOSAR ones.
Then consultants got involved and made it into the garbage it is. The ideas themself were sound and obvious. However they over complicated it and made it into garbage even though the idea itself is sound. (over complicated as in I know experienced autosar developers who got fed up and took 1 week to rewrite in C code they had just done in autosar in 3 months!)
So code reuse for cars, yes, that's a good idea. But that's hardly revolutionary, it's barely even an idea, it's certainly not unique. It's like saying world peace is a great idea, or solving world hunger, okay, so then what? How's that idea actually implemented? Terribly (which we agree on).
To be honest, I don't think we disagree that much, just arguing over very minor points. I happened to chose your comment to reply to instead of another, it should really be viewed as a generic rant against AUTOSAR instead of against anything you've said.
I think I'm taking the view the software is theorem building, it is a bunch of ideas, thus AUTOSAR is a bad idea. Sure, you could argue the core idea is a good idea, but "reusable software", or even "reusable software for industry X" is barely an idea, it's "nice things are nice".
What exactly? Will your proposed change make the cars more reliable? Cheaper to produce? What is the benefit?
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.
If your program is hello world complexity then it isn't worth the cost to make it reusable, just write and maintain 100 different copies - meanwhile elsewhere there are only 5 copies of the transmission controls and since it is only 5 it didn't get to the top of the list to fix redundancy - but those controls are very complex and making one version would be well wroth the effort.