Depends on the manufacturer. A lot of American and European “smart” cars work fine without an internet connection. You need to use a key fob, and apps cloud maps or streaming apps obviously won’t work, but the basic driving, climate, and media stuff should work.
A lot of American and European cars actually kill your cloud service access if you don’t keep paying a subscription fee.
Cloud connected cars are essentially what happens when companies refuse to admit smart phones are superior for 99% of the stuff they want their car to do, and the other 1% is subscription bullshit.
I think they keep an IOT connection alive to get the data they need from the car, they just kill your enjoyment of it. What happens if it would truly drop, your guess is as good as mine.
And that is with vested manufacturers. With startups it could be much worse.
Absolutely, in that the more software in a vehicle, the more likely it is to brick once a company folds. ICE cars are less likely since they don’t have most of the software, but there are some that are computers on wheels still (and I’m sure the amount will continue to increase).
ICE vehicles have more software because they have more components. They have a transmission control module and an engine control module both of which have a lot of sensors to read and outputs to control. Much more than a simple EV would have.
In 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.
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.
Seems like that is ripe for a class action. If a piece of hardware ceases to function if you don’t pay a fee but then the ability to pay is denied or removed the hardware should default to functioning. Come on EU, this is right up your alley, let’s get some laws made over there so us lowly Americans can benefit!
It’s not even a difficult law to pass, “if a cloud service goes out of business, its software becomes public domain. If the company is acquired, the sale must include a promise to keep the services operational for the full lifetime of the product unless the software is public domained”
Scary to think that the answer will be no.
Depends on the manufacturer. A lot of American and European “smart” cars work fine without an internet connection. You need to use a key fob, and apps cloud maps or streaming apps obviously won’t work, but the basic driving, climate, and media stuff should work.
A lot of American and European cars actually kill your cloud service access if you don’t keep paying a subscription fee.
I have zero use for a cloud connected car lol.
Cloud connected cars are essentially what happens when companies refuse to admit smart phones are superior for 99% of the stuff they want their car to do, and the other 1% is subscription bullshit.
Nah they’re using that cloud connection to spy on you and make money on the backend by selling your data.
Also to be able to disable certain functionalities of your car if you don’t pay a
monthly ransomsubscription.Not in the EU they’re not.
Legally they can’t and if they do it and get caught the fines are proportional to their Worldwide Revenues.
I have zero desire for a cloud connected car.
I think they keep an IOT connection alive to get the data they need from the car, they just kill your enjoyment of it. What happens if it would truly drop, your guess is as good as mine.
And that is with vested manufacturers. With startups it could be much worse.
The data they want, not need.
Potato/potato…
Makes you wonder about ice cars too.
Absolutely, in that the more software in a vehicle, the more likely it is to brick once a company folds. ICE cars are less likely since they don’t have most of the software, but there are some that are computers on wheels still (and I’m sure the amount will continue to increase).
ICE vehicles have more software because they have more components. They have a transmission control module and an engine control module both of which have a lot of sensors to read and outputs to control. Much more than a simple EV would have.
In 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.
Right but both EVs and ICE vehicles have infotainment systems. ICE vehicles have more components that require software in addition to that.
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.
Maybe just in terms of their electronics, such as updates and extended services.
I do wonder if things like heated seat subscription in EV’s and ICE car’s will keep functioning after the company disappears.
Seems like that is ripe for a class action. If a piece of hardware ceases to function if you don’t pay a fee but then the ability to pay is denied or removed the hardware should default to functioning. Come on EU, this is right up your alley, let’s get some laws made over there so us lowly Americans can benefit!
It’s not even a difficult law to pass, “if a cloud service goes out of business, its software becomes public domain. If the company is acquired, the sale must include a promise to keep the services operational for the full lifetime of the product unless the software is public domained”
The difficulty is in explaining what any of that means to the people who make the laws.
Probably not. But that’s what happens when you buy Things as a Service.
Yeah they’ll likely end up melting once global temperatures rise high enough.