My point is that vehicle control software that ends up in centralized systems tends to be bigger because the philosophy of making software for embedded systems (not just the core program but also libraries) is very different than that for systems with microprocessors: embedded systems with microcontrollers tend to have a few tends of KB of program memory per computing node and hence don’t even have an OS most of the time and the programs have to be coded to fit there as do the libraries, whilst the same functionality implemented in a centralized system alongside with that for things like UI touch controls, route navigation, audio system control, interfacing with smartphones and so on (doesn’t even need to include infotainment), tends to have more lines of code to do the same thing and use big libraries simply because there is no real memory size pressure on coders to make the programs ultra small and use tiny libraries.
So the paradox is that if you add more processing nodes to a system (such as in a car) in the form of microcontrollers and move some functionality to run there rather instead of in the central more powerful computing node, you will probably end up with fewer lines of code purelly because the software design philosophy for microcontrollers emphasises smaller size and less overhead (hence why they don’t usually have an OS), whilst that for systems with actual microprocessors does not hence the software tends to be a lot more bloated.
(The complaint from older software programmers that software nowadays is much more bloated is true. However microcontrollers are like the microprocessors of 30 years ago - say 4KB RAM, 64KB storage flash memory and a 40MHz clock - so the code for those is till forced to be done lean and mean, otherwise it wont fit or perform)
So if you measure “amount of software” by “code size”, then ICEs will have less software because they tend to use a distributed system design with lots of small computing nodes, for historical reasons (they existed back in the days when electronics was moving to using software running in microcontrollers instead of discrete logic in hardware or PLAs) and possible also because some of the things they have to do which are not required for EVs (such as injection control) have very tight time constraints and the best way to make sure your software reliably works with ms or sub-ms margins is to not even have an OS and coding that software to be small with very tightly controlled code execution in something like C and even with ASM for more critical stuff.
However if you measure “amount of software” by “number of individual functionalities it covers” (so, roughly, the number of programs in the whole system), then your are correct that all else being the same ICEs have more software because more functions have to be covered to control an ICE system.
Right, the centralized control systems that get bloated with software are not unique to EVs. Like I said. And those centralized control systems have more inputs and outputs to interact with on an ICE than on an EV because an ICE has more components.
I’m not a hobbyist. I was a master automotive mechanic for over 20 years and I am now a software developer. I feel the need to say this because you are restating the same points I already address in a more verbose way as if you are hoping to make it sound too complicated for the average person to refute.
My point is that vehicle control software that ends up in centralized systems tends to be bigger because the philosophy of making software for embedded systems (not just the core program but also libraries) is very different than that for systems with microprocessors: embedded systems with microcontrollers tend to have a few tends of KB of program memory per computing node and hence don’t even have an OS most of the time and the programs have to be coded to fit there as do the libraries, whilst the same functionality implemented in a centralized system alongside with that for things like UI touch controls, route navigation, audio system control, interfacing with smartphones and so on (doesn’t even need to include infotainment), tends to have more lines of code to do the same thing and use big libraries simply because there is no real memory size pressure on coders to make the programs ultra small and use tiny libraries.
So the paradox is that if you add more processing nodes to a system (such as in a car) in the form of microcontrollers and move some functionality to run there rather instead of in the central more powerful computing node, you will probably end up with fewer lines of code purelly because the software design philosophy for microcontrollers emphasises smaller size and less overhead (hence why they don’t usually have an OS), whilst that for systems with actual microprocessors does not hence the software tends to be a lot more bloated.
(The complaint from older software programmers that software nowadays is much more bloated is true. However microcontrollers are like the microprocessors of 30 years ago - say 4KB RAM, 64KB storage flash memory and a 40MHz clock - so the code for those is till forced to be done lean and mean, otherwise it wont fit or perform)
So if you measure “amount of software” by “code size”, then ICEs will have less software because they tend to use a distributed system design with lots of small computing nodes, for historical reasons (they existed back in the days when electronics was moving to using software running in microcontrollers instead of discrete logic in hardware or PLAs) and possible also because some of the things they have to do which are not required for EVs (such as injection control) have very tight time constraints and the best way to make sure your software reliably works with ms or sub-ms margins is to not even have an OS and coding that software to be small with very tightly controlled code execution in something like C and even with ASM for more critical stuff.
However if you measure “amount of software” by “number of individual functionalities it covers” (so, roughly, the number of programs in the whole system), then your are correct that all else being the same ICEs have more software because more functions have to be covered to control an ICE system.
Right, the centralized control systems that get bloated with software are not unique to EVs. Like I said. And those centralized control systems have more inputs and outputs to interact with on an ICE than on an EV because an ICE has more components.
I’m not a hobbyist. I was a master automotive mechanic for over 20 years and I am now a software developer. I feel the need to say this because you are restating the same points I already address in a more verbose way as if you are hoping to make it sound too complicated for the average person to refute.