Speculation Lucid UX 3.0

[koflo]

Hardware is the part you cannot fix, I trust lucid will do software the justice it deserves.

I hope so too but I’ll just say that if we all held our breath for that to happen we’d all be dead a long time ago

 

[maractwin]

Hardware is the part you cannot fix, I trust lucid will do software the justice it deserves.

That attitude is a lot of the problem with Lucid right now. Good software takes as long to write as the hardware takes to design and produce. And poor hardware decisions can make the software exponentially harder to get right.

I'm a retired software engineer who has worked on some embedded systems and dealt with some of these issues. For example, conventional cars have one computer running the infotainment systems and another running the engine. But Lucid seems to have dozens of computers doing different things networked together. So they have the complexity and synchronization issues of a distributed system within the car. That leads to problems like weird behavior following a software update because some but not all of the computers got rebooted. Or two audio sources playing simultaneously because different computers send audio streams to the computer that runs the speakers--that wouldn't happen in a conventional setup with a single computer running infotainment.

 

[joec]

That attitude is a lot of the problem with Lucid right now. Good software takes as long to write as the hardware takes to design and produce. And poor hardware decisions can make the software exponentially harder to get right.

I'm a retired software engineer who has worked on some embedded systems and dealt with some of these issues. For example, conventional cars have one computer running the infotainment systems and another running the engine. But Lucid seems to have dozens of computers doing different things networked together. So they have the complexity and synchronization issues of a distributed system within the car. That leads to problems like weird behavior following a software update because some but not all of the computers got rebooted. Or two audio sources playing simultaneously because different computers send audio streams to the computer that runs the speakers--that wouldn't happen in a conventional setup with a single computer running infotainment.

My understanding is they have corrected this with Gravity. But it will continue to be a problem in any Air until they refresh the computer system. Likely not for a few more years.

 

[segbrk]

Or two audio sources playing simultaneously because different computers send audio streams to the computer that runs the speakers--that wouldn't happen in a conventional setup with a single computer running infotainment

I think it is still a single infotainment computer? The other computers are for ADAS, traction control, etc. Separation there is a good thing. You really don't want those other critical systems hanging because a bug in a music player app is tanking the infotainment computer. It is more complex, but it's also practically necessary. I'm almost certain the multiple audio streams issue is purely in software. Lucid's infotainment is based on Android, Android has a system level soft mixer for playing multiple streams at once. It just normally shouldn't play two actual media streams at once. But it has the mixer so that e.g. notification sounds and navigation instructions can play over media.

 

[borski]

I just want to build a car with a memory-safe and statically typed language. Is that too much to ask? Why do we have to use Android Automotive and all the Java that comes with it, and force ourselves to deal with asinine concurrency nonsense just because everyone else does it that way?

Why can’t we just do it right?

Signed,
a sad engineer who knows we could do better

 

[koflo]

I just want to build a car with a memory-safe and statically typed language. Is that too much to ask? Why do we have to use Android Automotive and all the Java that comes with it, and force ourselves to deal with asinine concurrency nonsense just because everyone else does it that way?

Why can’t we just do it right?

Signed,
a sad engineer who knows we could do better

Does everyone else do it that way though? Pretty sure the gold standard EV softwares do not use android as a foundation. I could see others definitely. But the Rivians and Teslas of the world I do not believe do.

 

[HC_79]

Does everyone else do it that way though? Pretty sure the gold standard EV softwares do not use android as a foundation. I could see others definitely. But the Rivians and Teslas of the world I do not believe do.

Rivian uses Android Automotive. Google and Rivian confirmed it. Makes you wonder wtf Lucid did!

 

[koflo]

Rivian uses Android Automotive. Google and Rivian confirmed it. Makes you wonder wtf Lucid did!

Well crap. Yeah idk then. I stand corrected. If it’s working that well for rivian then yeah I’m right there with ya, idk how the experiences can be so drastically different. Well I do but it’s mind blowing to me that it’s as drastic as it is.

 

[borski]

Well crap. Yeah idk then. I stand corrected. If it’s working that well for rivian then yeah I’m right there with ya, idk how the experiences can be so drastically different. Well I do but it’s mind blowing to me that it’s as drastic as it is.

Rivian software is solid in spite of it being built on Android Automotive; not because of it.

 

[DeaneG]

Rivian software is solid in spite of it being built on Android Automotive; not because of it.

It's fine in our Volvo too, and the implementation in the Polestar 3 is said to be great.
Device OS software has a very long lifecycle and so tends to not be at the forefront of technology. Memory-safe languages are only now making significant inroads, and that with Google pushing it. It'll be a while before an OS is built fully memory-safe.

Rust as a new programming language for platform code​

Android 12 introduced Rust as a platform language. Rust provides memory and thread safety at performance levels similar to C/C++. We expect Rust to be the preferred choice for most new native projects. However, rewriting all memory unsafe code, currently representing over 70% of the Android platform code, in Rust isn't feasible. Moving forward, Rust will be complementary to memory safety tools."

The reason that a dozen or more auto manufacturers have adopted AAOS is that it gives access to a number of capabilities and existing third party apps that will grow with time, and access to Google's cloud infrastructure. It would be a immense project to start from scratch.

I can see though how little of this potential advantage is currently being gainfully used by Lucid, and how iPhone users basically wouldn't care.

 

[xponents]

Can somebody ELI5 (or ELI15, lol) what a memory-safe language is (in terms of automotive software), and more importantly, how it would be better than Android Automotive? Thanks!

 

[DeaneG]

Can somebody ELI5 (or ELI15, lol) what a memory-safe language is (in terms of automotive software), and more importantly, how it would be better than Android Automotive? Thanks!

They're two different things.

What is memory safety and why does it matter?

Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used. Since memory safety bugs are often security issues, memory safe languages are more secure than languages that are not memory safe. Memory safe...

www.memorysafety.org

An operating system, which is present in most complex computer-operated devices, provides an environment and services which can run other software applications. Services like communication (wifi, canbus, etc), queues, filesystems, sometimes diagnostics. The operating system must be written in some combination of languages. Memory-safe languages eliminate a class of common bugs by design. Older languages, like C and C++, are prone to accidental misuse and purposeful abuse, giving rise to those bugs and also to security vulnerabilities.

The applications running on the operating system provide the function and personality you see in a product. Like the dashboard interface and the apps in a car, as well as its ability to do OTA updates, communicate with service, wake from sleep to charge, etc.

Operating systems designed for use in products like phones, cars, complex toys, etc often have a useful lifecycle in the range of 10+ years. They take a lot of effort to develop, can be quite complex, and customers contractually demand a long support lifetime. So historically they are not built on bleeding-edge software technology, and take some time to re-engineer when better tech comes along.

 

[HariK]

QNX vs AA Pros and Cons. https://androidautomotive.dev/blog/qnx-vs-aaos
I agree with the conclusive comments. "QNX-based infotainment isn’t seen as a viable competitor to AAOS. However, Blackberry’s lower-level safety systems can work alongside an Android interface to deliver the ultimate driving experience that’s both secure and pleasant to navigate."

 

[DeaneG]

QNX vs AA Pros and Cons. https://androidautomotive.dev/blog/qnx-vs-aaos
I agree with the conclusive comments. "QNX-based infotainment isn’t seen as a viable competitor to AAOS. However, Blackberry’s lower-level safety systems can work alongside an Android interface to deliver the ultimate driving experience that’s both secure and pleasant to navigate."

Volvo and Polestar use an RTOS (QNX??) for safety related functions (at least for speedometer and other instrument displays), and AAOS for infotainment app functions. IMO it's a good mix. I've read that both are run in VMs on a very old CPU. It's slow to boot with the most recent AAOS version update but reasonably responsive after a minute or two. Newer implementations are instantly responsive.

 

[HariK]

Volvo and Polestar use an RTOS (QNX??) for safety related functions (at least for speedometer and other instrument displays), and AAOS for infotainment app functions. IMO it's a good mix. I've read that both are run in VMs on a very old CPU. It's slow to boot with the most recent AAOS version update but reasonably responsive after a minute or two. Newer implementations are instantly responsive.

They for sure use QNX in 2021. https://blogs.blackberry.com/en/202...ckberry-qnx-for-its-dynamic-software-platform

 

[borski]

It's fine in our Volvo too, and the implementation in the Polestar 3 is said to be great.
Device OS software has a very long lifecycle and so tends to not be at the forefront of technology. Memory-safe languages are only now making significant inroads, and that with Google pushing it. It'll be a while before an OS is built fully memory-safe.

Rust as a new programming language for platform code​

Android 12 introduced Rust as a platform language. Rust provides memory and thread safety at performance levels similar to C/C++. We expect Rust to be the preferred choice for most new native projects. However, rewriting all memory unsafe code, currently representing over 70% of the Android platform code, in Rust isn't feasible. Moving forward, Rust will be complementary to memory safety tools."

The reason that a dozen or more auto manufacturers have adopted AAOS is that it gives access to a number of capabilities and existing third party apps that will grow with time, and access to Google's cloud infrastructure. It would be a immense project to start from scratch.

I can see though how little of this potential advantage is currently being gainfully used by Lucid, and how iPhone users basically wouldn't care.

I don’t disagree with anything you said, but I want someone to build the software for a car in a language that lends itself to sane defaults and keeps you from shooting yourself in the foot. Yes, I recognize that’s a tall order and a pipe dream. Let me dream.

Can somebody ELI5 (or ELI15, lol) what a memory-safe language is (in terms of automotive software), and more importantly, how it would be better than Android Automotive? Thanks!

Long story short: programming languages interact with various bits of memory. One of the most common bugs, as an example, is a race condition; two threads or programs running simultaneously and accessing the same bit of memory. One changes it, but the other is unaware, and is now working with outdated or wrong data; they “race” to the memory and the one that gets there first wins. That leads to confusion, crashes, and bugs.

That is a “concurrency” bug, and there are ways to resolve it; various types of locks, semaphores, and other inter process communication / memory sharing techniques.

But in a memory-safe language, race conditions literally cannot happen. Your phone and your media literally could not “accidentally” start playing at the same time, because you couldn’t have forgotten to handle the memory access and lock it, because the language won’t let you.

None of that has anything to do with Android Automotive. AA is written in Java, which is dynamically typed (“is this an integer or a string? Meh, I’ll just let the compiler figure it out for me”) and not memory safe. Java sucks. Anyone that does you otherwise writes Java for a living and has Stockholm syndrome. (Don’t @ me lol)

 

[joec]

I don’t disagree with anything you said, but I want someone to build the software for a car in a language that lends itself to sane defaults and keeps you from shooting yourself in the foot. Yes, I recognize that’s a tall order and a pipe dream. Let me dream.


Long story short: programming languages interact with various bits of memory. One of the most common bugs, as an example, is a race condition; two threads or programs running simultaneously and accessing the same bit of memory. One changes it, but the other is unaware, and is now working with outdated or wrong data; they “race” to the memory and the one that gets there first wins. That leads to confusion, crashes, and bugs.

That is a “concurrency” bug, and there are ways to resolve it; various types of locks, semaphores, and other inter process communication / memory sharing techniques.

But in a memory-safe language, race conditions literally cannot happen. Your phone and your media literally could not “accidentally” start playing at the same time, because you couldn’t have forgotten to handle the memory access and lock it, because the language won’t let you.

None of that has anything to do with Android Automotive. AA is written in Java, which is dynamically typed (“is this an integer or a string? Meh, I’ll just let the compiler figure it out for me”) and not memory safe. Java sucks. Anyone that does you otherwise writes Java for a living and has Stockholm syndrome. (Don’t @ me lol)

I'm so very glad Swift 6 will soon be getting strict concurrency checking.

Now, if only Apple were still making a carOS…

 

[borski]

I'm so very glad Swift 6 will soon be getting strict concurrency checking.

Now, if only Apple were still making a carOS…

Maybe I need to write a car OS in elixir. It can’t be that hard, right? But like, I’d need a car to run it on…

 

[DeaneG]

Now, if only Apple were still making a carOS…

IMO Apple has so far neglected a huge opportunity there. An Apple car made no sense, a huge capital undertaking with low margins and difficulty in product differentiation. But I think an automotive OS that could run native Apple Maps, Apple Music, etc would be attractive to auto manufacturers and a big draw for many car buyers.

 

[DeaneG]

Maybe I need to write a car OS in elixir. It can’t be that hard, right? But like, I’d need a car to run it on…

You'd also need to write all the possible car apps, and maybe provide and maintain a solid cloud infrastructure for OTA updates and EV performance data gathering (trip consumption analysis and prediction).