SW experts - limits to OTA pipe?

[EdL-ATX]

As I super impatiently await UX2.0, I am increasingly curious about what would technically limit/throttle OTA rollouts.

I'm a hardware/Silicon engineer so not as familiar with SW limitations. Asking the resident software experts.

There really aren't many Airs in the field at this point. We're all familiar with devices where OTA updates go out simultaneously to a much broader population - many orders of magnitude higher.

So as Lucid scales, what would you speculate has to be changed in their infrastructure to push out updates to a larger population in parallel?

Obviously I'm assuming they are not artificially limiting it at this stage (which they might do if they had low confidence in the quality of the updates, for example).

Just feeding my engineering curiosity while refreshing the app constantly

 

[Ksa23]

Lucid rolling out slowly isn't a bandwidth or technology problem. I can transmit 5gb of data to 1000 destinations in a day from a 15 year old computer. I suspect they are just overly cautious in releasing their updates incase a bug or issue is found, the scope is limited.

We follow this practice in the world of IT as well, even for highly reliable software packages -- slow deployments to ensure it's as smooth as possible.

They cant afford any negative PR or mass recalls this early into their development.

 

[borski]

Yeah, they stage rollouts to ensure if some showstopper comes up (which there is always a chance of) they don’t brick the entire fleet.

I would do the same thing.

Incidentally, Apple and others don’t do this because they have many thousands of beta testers (aka developers) who test it before it goes live to the public.

 

[joec]

Yeah, they stage rollouts to ensure if some showstopper comes up (which there is always a chance of) they don’t brick the entire fleet.

I would do the same thing.

Incidentally, Apple and others don’t do this because they have many thousands of beta testers (aka developers) who test it before it goes live to the public.

Even Apple gives individual developers the option to batch updates. Companies with millions of customers take advantage of that pretty often.

With smaller apps, it's less of a concern.

 

[borski]

Even Apple gives individual developers the option to batch updates. Companies with millions of customers take advantage of that pretty often.

With smaller apps, it's less of a concern.

True.

 

[SDHacker]

My team was responsible for software that ran on over 15k Unix servers. Ran new releases in dev then test environments (and many applications view their test environment like their production one). Then we separated servers by hardware platforms. Then we ran batches within those groupings. Customers, clients, and the C suite don’t care how confident you are about your software - only that it works. Blasting software out at the same time to 2 ton killing machines that can physically interact with other heavy killing machines isn’t a show of confidence. Our safety and the safety of those around us is dependent on that software so they better take every precaution. That includes batching and slow rolling releases to production.

The attitude of some on this forum seems to treat the software running this car like an app on your laptop or phone. It’s not going to kill you or someone else if your laptop or phone flakes out. I hope thinking of software like that will help you be a little more patient and understanding of why they don’t just blast out updates to everyone.

 

[EdL-ATX]

Sure. I wasn't necessarily looking for a lecture on how a car or a plane is different from a phone.

They will have quality requirements that are different from average consumer electronic device - even before going to ONE car.

But since they inherently tout their ability to improve our cars/experience as time goes on AND the total number of cars in the field will continue to increase, I was trying to understand if there are technical challenges in updating a growing fleet vs "just" a risk management rollout strategy. I feel that was answered based on the experience folks have in other areas of SW development.

 

[joec]

Sure. I wasn't necessarily looking for a lecture on how a car or a plane is different from a phone.

They will have quality requirements that are different from average consumer electronic device - even before going to ONE car.

But since they inherently tout their ability to improve our cars/experience as time goes on AND the total number of cars in the field will continue to increase, I was trying to understand if there are technical challenges in updating a growing fleet vs "just" a risk management rollout strategy. I feel that was answered based on the experience folks have in other areas of SW development.

Yeah, as the fleet grows, the time it takes for rollout will increase, for sure. I sometimes wait weeks now for met to get Tesla updates that friends have already gotten. Other times, I get it way before them.

It'll matter less when it isn't a super highly anticipated release like the 2.x is for Lucid right now. I expect most releases to be pretty hum-drum. To the point where most customers won't care when they get it. There will always be exceptions. Like CarPlay / Android Auto. Or whenever they add more functions to the ADAS system. But that will be increasingly rare as time goes on.

There will also hopefully be fewer firmware discrepancies between different cars once the supply chain is more under control, and once Lucid gets big enough to make stricter demands on vendors.

Batching, however, will always remain necessary for safety reasons.

 

[Rogue]

Deployment systems have become super powerful and sophisticated tools. Some of them handle scaling for you. Some require other tools to pitch in. Azure, AWS, or whatever backend they are leveraging allows you to scale at need and simply sends the bill based on usage.

This area is not an area of extensive knowledge on my part, nor has it ever been a factor at places I have worked. However, the above gets you most of the way there conceptually. Tools exist. The guy from Apple will be familiar with said tools. Lucid is in good hands.