4 ms·

Misra rules are not what is wrong with automotive software development. I would say it is like 99% a wage problem.

SV_BubbleTime 3y ago
I’m much closer to this. A few issues… - Most people have no idea how many modules there are in their vehicles. It’s a LOT more code than you realize. - Companies like ERAS, Vector, Kvaser, Mentor, Bosch, and others have a great lock on software for systems they steer via SAE and ISO. - AutoSar and other shitty systems. It doesn’t matter how good your programmers are if they are kneecapped out the gate. - Same as any programming lately at big companies… it’s 10 managers to every actual programmer. - Outsourced. When I was at a Chrysler, code was worked on, released, and tested locally for some modules. Now… often times no one at Chrysler may even be allowed to see code. A LOT of work is done in India. MISRA isn’t even close to a problem in automotive. And I disagree it’s a wage problem. You could pay the engineers in India more, and it still wouldn’t give them any idea how the consumer will use the end product. It doesn’t help them understand repair/replace diagnostics. No one is monitoring the ever increasing complexity of the systems as a whole. Overall, cars do work well. But damn if they aren’t trying to ruin that.
- rightbyte 3y ago
  Ye maybe. Agile is a nightmare in automotive since the process is so strict and the ensuing micromanagement makes doing thing a gigantic burden. Companies like Bosh have a strange dev process where they don't want to change code but instead make almost everything tunable by parameters so that you essentially can program via config, to get around some internal process. Their code is a nightmare to interface with. AutoSar is a joke. I would rather each device have their own API then dealing with that dynamic complex mess.
- P_I_Staker 3y ago
  I'm very disturbed by some things, specific to the most recent vehicles especially. Lots of design done by competing teams that have tons of incentive to say things like "not my problem!", and point fingers. Somewhat related to the proliferation of AutoSAR, but AutoSAR is just the solution, whether you like it or not. It could be replaced with some hypothetical "PerfectSAR", and this remains true. None of this is exactly brand new. That said, the extent of the situation is worrying. Combine with this that we're trying to deliver so much more on tighter schedules... seems like a recipe for disaster.
iso8859-1 3y ago
Is it possible to make a fuel efficient open source car that is road legal? How much funding would it require?
- rightbyte 3y ago
  The main cost is probably designing the hardware. Programming simple ECUs without bloat for a car is done quickly. Except the engine and ABS system. You got sensitive control loops in those. Those two systems is probably almost all programming work.
  - iso8859-1 3y ago
    I had imagined that the main cost would be certification. But maybe if the hardware is similar enough to an already certified veteran car , you could piggyback off of that. OTOH I've heard can't even swap out the engine of an old car without it needing re-certification.

I’m much closer to this. A few issues… - Most people have no idea how many modules there are in their vehicles. It’s a LOT more code than you realize. - Companies like ERAS, Vector, Kvaser, Mentor, Bosch, and others have a great lock on software for systems they steer via SAE and ISO. - AutoSar and other shitty systems. It doesn’t matter how good your programmers are if they are kneecapped out the gate. - Same as any programming lately at big companies… it’s 10 managers to every actual programmer. - Outsourced. When I was at a Chrysler, code was worked on, released, and tested locally for some modules. Now… often times no one at Chrysler may even be allowed to see code. A LOT of work is done in India. MISRA isn’t even close to a problem in automotive. And I disagree it’s a wage problem. You could pay the engineers in India more, and it still wouldn’t give them any idea how the consumer will use the end product. It doesn’t help them understand repair/replace diagnostics. No one is monitoring the ever increasing complexity of the systems as a whole. Overall, cars do work well. But damn if they aren’t trying to ruin that.

rightbyte 3y ago
Ye maybe. Agile is a nightmare in automotive since the process is so strict and the ensuing micromanagement makes doing thing a gigantic burden. Companies like Bosh have a strange dev process where they don't want to change code but instead make almost everything tunable by parameters so that you essentially can program via config, to get around some internal process. Their code is a nightmare to interface with. AutoSar is a joke. I would rather each device have their own API then dealing with that dynamic complex mess.
P_I_Staker 3y ago
I'm very disturbed by some things, specific to the most recent vehicles especially. Lots of design done by competing teams that have tons of incentive to say things like "not my problem!", and point fingers. Somewhat related to the proliferation of AutoSAR, but AutoSAR is just the solution, whether you like it or not. It could be replaced with some hypothetical "PerfectSAR", and this remains true. None of this is exactly brand new. That said, the extent of the situation is worrying. Combine with this that we're trying to deliver so much more on tighter schedules... seems like a recipe for disaster.

iso8859-1 3y ago

Is it possible to make a fuel efficient open source car that is road legal? How much funding would it require?

rightbyte 3y ago
The main cost is probably designing the hardware. Programming simple ECUs without bloat for a car is done quickly. Except the engine and ABS system. You got sensitive control loops in those. Those two systems is probably almost all programming work.
- iso8859-1 3y ago
  I had imagined that the main cost would be certification. But maybe if the hardware is similar enough to an already certified veteran car , you could piggyback off of that. OTOH I've heard can't even swap out the engine of an old car without it needing re-certification.