Comment on When EV startups shut down, will their cars still work?
Aceticon@lemmy.world 3 weeks agoIn my experience (mostly as a hobbyist and not in cars), embedded systems software (i.e. running in microcontrollers) is way smaller than the kind of stuff running in entertainment systems which require the power of microprocessors.
It’s pretty much an entirelly different class of software and even the libraries used are done with entirelly different primary objectives (generally small size is more important than just about everything else in the embedded system world).
ICE cars will have more microcontrollers (all communicating with each other via CAN), but the sofware within most of them is something that fits a few tens of KB of memory, whilst the software managing the used interface even if the screen is only 1024x768 (which looks like crap even compared to the cheapest of smartphones), will be tens of hundreds of megas worth of code + data.
UsernameHere@lemmy.world 3 weeks ago
Right but both EVs and ICE vehicles have infotainment systems. ICE vehicles have more components that require software in addition to that.
Aceticon@lemmy.world 3 weeks ago
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 even 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), if most are embedded systems you will probably end up with fewer lines of code than if most of that same software was implemented for and running in a more powerful central system, 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.
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.
UsernameHere@lemmy.world 3 weeks ago
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.
Aceticon@lemmy.world 3 weeks ago
You misinterpreted my intention - that’s how I normally present things from my domain of expertise and I was actually making an effort to simplify it and not use too much domain specific slang.
Since you’ve pulled the expertise card out, I’m a Technical Architect with 30 years experience in software engineering, having working all the way up from a software developers, in several countries, several domains of software engineering and even for several industries, and amongst other things that includes Android, iOS, Linux-based and Windows-based systems, both frontend and backend, which is applicable for modern centralized user control systems for cars as well as infotainment systems, and those are just a fraction of the kind of areas in software design and developement I worked in.
I only said I was a hobbyist very specifically in embedded systems software because even though I have an EE degree and have 3 decades of professional experience in other software development domains, I only ever did software for embedded systems for fun - though I have some years of it - not for work, and I was hardly going to claim I was a bloody professional in a specific domain of software engineering were I did not work as a professional.
So yeah, if there’s something I know about is how the number of inputs and outputs influences the size of the code (very little, as that’s not were the complexity lies) and how software running in weaker computing units is way smaller and much more optimized than software running in powerful computing units because the very software developers themselves (at all levels, including OS and libraries) learn from experience very different lessons about how much time they should spend making their code small and tight when they are working with weaker processing units versus working with powerful processing units.