
Automotive Grade Linux - known
https://www.automotivelinux.org/
======
lmilcin
I like Linux and used it for over 22 years now, I did some kernel development.
I worked for Samsung on TizenOS and I had some discussion with Intel on IVI
(their offshoot for automotive). I then went to work for Intel. In my opinion
one thing Linux is never going to be is "automotive grade".

There is conflicting set of requirements when developing Linux and in the end
it is somewhere on the spectrum of compromise between performance, security,
stability, features and development cost.

And I think this is right, Linux is real software for real world and it would
be wrong and wasteful for general purpose OS to prioritize one requirement to
the exclusion of others.

Unfortunately, an automotive grade software absolutely requires focus on
stability and you just can't get it if you also want performance, features and
want to do it cheap.

I am also of the opinion that Linux is just way too complex to ever be stable
enough for controlling your car. Think about Android. You get an OS tightly
managed by Google, running on purpose-built hardware (I have Pixel 2 XL) and
it still regularly crashes on me and does otherwise funky things. I have no
illusions car industry is going to be able to do any better.

Now, I have nothing against using Linux for everything else in a car
(infotainment, navigation, etc.) but I would not trust one that will have
anything to do with basic controls.

~~~
raxxorrax
As someone who develops mostly bare metal embedded systems, not everything
that is simple is also golden and stable, especially compared to the Linux
kernel.

Honestly I have never heard of a case where a OS too complex to be the cause
of catastrophe. Embedded systems on the other hand...

I think the maturity of kernels of popular OS are much more battle tested than
a standalone system can ever be at this point. Sure, maybe don't give
essential controls to any complex (technical) system without the driver being
able to correct. Just look at Boeing and MCAS, probably not based on Linux.

I think the automotive industry currently has the problem that it too often
relied on proprietary systems and buses. An open system could handle the
diversity of suppliers very common for most manufacturers. It can supply a
common base to develop against. I don't think it is fair to compare the
stability of Linux to Android, they are worlds apart.

Teslas OS is based on Linux, so we have a case were it does indeed work at
least for supplemental functions. And I fear alternative choices could be the
death of other manufacturers because their software would fall behind.

~~~
turbinerneiter
I have seen software for a unit in a car which had no safety relevant tasks,
which was written using a custom, homegrown rtos with half of a standard
library reimplemented from scratch for no reason at all.

Their supplier did all of this on purpose, to create lock-in, which worked -
now they charge by line of code.

Any old Linux kernel haphazardly patched together to run on the target would
be better than this garbage.

Do airplanes still run an emulator for a chip that is no longer produced
because nobody wants to port the software? That was a fun story I still hope
is an urban myth.

~~~
m4rtink
A lot if not the majority or PoS terminals around here run som DOS software,
usually on top of an emulator. Sometimes you can even see a DOSBox window on
top of a Windows desktop.

~~~
franga2000
Just a few months ago I caught a glimpse of DOS in a multi-national home
improvement store. Turns out _all_ of their computers are fairly recent
ThinkCentre machines, all running Windows 7 that is locked down to 3 programs:
calc.exe, Internet Explorer 10 and some proprietary DOS emulator they pay
something like 50k€ annually for, running a TUI client for their inventory and
order system.

I don't even know how to sort those by level of stupidity...

------
rightbyte
"Reference applications including media player, tuner, navigation, web
browser, Bluetooth, WiFi, HVAC control, audio mixer and _vehicle controls_ "

It is nice to have a alternative to Google's car spy software, but I am
suspicious of any ECU containing _malloc_. If ECUs gets so complicated that
they require Linux maybe there just is a fundamental design issue.

(EDIT: ECU as in Electric control unit, not only the Engine control unit.)

~~~
bpoyner
For Mazda, Linux is used in the infotainment system. There is an entire
community built around tweaking that infotainment system, and somebody has
bundled those into a package called Mazda All In One Tweaks. They've done some
pretty impressive stuff, such as adding Android Auto support before Mazda
officially did. [https://github.com/Trevelopment/MZD-
AIO/](https://github.com/Trevelopment/MZD-AIO/)

~~~
izacus
Even more, the Mazda's UI (like many other car infotainment stacks) is
actually written in JavaScript. The infotainment boots into Opera browser and
renders whole UI as a webapp.

Otherwise it's a rather nicely designed system - using dbus for communication
without too much of a wierd hacks.

~~~
formerly_proven
A lot of the other stacks are using Qt Quick / QML.

~~~
throwaway894345
In a past life I built some of these displays with C++/Qt. At the time, QML
was still in alpha.

~~~
jschwartzi
You should take a look at QML. It's wonderful.

~~~
throwaway894345
I should take another look at it. Thanks for the reminder.

------
morganvachon
I was interested in dabbling with this project until I came across this
regarding Python support:

 _Note: Python 2.7.3 or greater excluding Python 3.x, which is not supported._

I'm not a developer by trade or talent, but I'm learning and I'm starting with
Python. Everything I've read and been told about Python development says to
start with 3.x because the 2.x branch is officially deprecated and should only
be targeted if one is intending to learn specifically for maintaining a legacy
project that still uses it. I'm learning to learn, not to work, so I think
I'll wait until AGL is brought up to a current version of the language before
I dive in and get myself confused.

Beyond that though, I do like the premise of having the infotainment stack
open source from the ground up. It would be nice if manufacturers would pay
attention to this project and write open source drivers for their hardware.

~~~
q3k
The Python 2 dependency would be on par for industrial/automotive stacks,
unfortunately. This area of the industry is not really up to date regarding
modern software development practices (sometimes for good reasons, but more
often not).

~~~
ravingraven
I work with embedded systems and I can tell you for a fact that there are
exactly two reasons for not including Python or newer versions of it:

1) Hardware constraints. 2) Software must be real-time.

Non-embedded developers are usually unable to understand the constrains of
embedded and chalk it up to "you are dinosaurs". Not true.

~~~
q3k
Sure, and I wouldn't run Python on embedded devices either [1] - and that's
not what I was suggesting in the first place.

The lack of Py3 support is not about Python vs $language on $environment, it's
about using EOL software in general.

[1] - my last public embedded software contribution was in fact an ELF loader
for a smartwatch so that I wouldn't have to use micropython:
[https://git.card10.badge.events.ccc.de/card10/firmware/-/tre...](https://git.card10.badge.events.ccc.de/card10/firmware/-/tree/master/epicardium/l0der)

~~~
ravingraven
Looks awesome!

------
tW4r
I really wish there were more beginner developer friendly diy options for car
entertainment. I’ve been considering making a carputer out of a raspberry pi,
however, half the solutions are proprietary (looking at Qt), however there
were some demos of this running on an rpi. So that is a nice development.

I’d rather just put a normal Linux distro there, however, I’m not feeling like
waiting 8 seconds every time I turn in my car.

Apple CarPlay is in the same boat requiring an MFi private certificate, and no
way to provision a short lived cert like they do for iPhones.

~~~
mschuster91
> I’d rather just put a normal Linux distro there, however, I’m not feeling
> like waiting 8 seconds every time I turn in my car.

Suspend-to-RAM works decently to avoid this, and to avoid it sucking the
battery dry, Suspend-to-Flash can be used. Yes this will take some time for
restoring RAM... but again, to avoid the user noticing that time, why not
start the wakeup process when the user unlocks their car / opens a door?

~~~
ColeyG
Do you have any resources or guides on how to get suspend to ram working?

~~~
stragies
Whenever I read comments like this, I think "Why is he trying to use a 10+
years old Ubuntu, or similar"? Or do I just make way luckier buying choices?
Suspend to anything has worked flawlessly out of the box for my devices since
10+ years. Do you have a specific example of what is not an "obviously bad
hardware combination choice", but yet still does not correctly support
Suspend-to-RAM?

~~~
jcelerier
> Suspend to anything has worked flawlessly out of the box for my devices
> since 10+ years.

lucky you - I have a laptop (GS65) where suspend-to-ram occasionally fails to
unsuspend, even on windows

------
crb002
Many manufactures use the Intel Windriver distro of Yocto. SQLite3 is king
just like on a mobile phone. Dbus/Qt for GUI applications. Froglogic Squish is
a PITA [https://www.froglogic.com/squish/editions/qt-gui-test-
automa...](https://www.froglogic.com/squish/editions/qt-gui-test-automation/)
\- need an open source alternative.

Test builds should have ksan/asan turned on by default.

Production builds should ruthlessly remove unused binaries and make heavy use
of --gc-sections to cull dead code. Even SQLITE3 should have features
whitelisted to make it more safe.

Several TLA+ and Alloy specs need to be written to ensure distro saftey.

------
trishankdatadog
"AGL includes the meta-updater Yocto layer that enables OTA software updates
via Uptane, an automotive-specific extension to The Update Framework. Uptane
and TUF are open standards that define a secure protocol for delivering and
verifying updates even when the servers and network–internet and car-
internal–aren’t fully trusted."

[https://docs.automotivelinux.org/docs/en/master/architecture...](https://docs.automotivelinux.org/docs/en/master/architecture/reference/security/part-8/1-FOTA.html)

------
adammunich
Half the battle is hardware, who's going to make the computers that will run
in Alaska, and Mexico, for 20+ years?

~~~
detaro
The same companies that have made the computers in cars or industrial control
systems for the last 10-20 years?

~~~
olyjohn
More like 35+ years. Honda has had electronic fuel injection systems that used
Intel chips at least as far back as 1985.

------
joshAg
For an infotainment system, or even things like AC and fan speeds, this sounds
pretty cool.

But for the dataplane software responsible for dashboard clusters and the
like, this scares the hell out of me, because linux isn't an RTOS and because
of all the ways you'd ahve to protect that system from anything else running
on that same kernel (eg: an update to applecar play or android auto
adds/exacerbates a resource leak). If the vehicle system was designed with
linux in mind from the beginning, having linux handle the data plane startup
and restart as well could be ok (because you'd probably make user-space
programs with direct hardware access to dedicated hardware and priority that
preempts the kernel to make the code as predictable as possible), but
combining the dataplane for driving the vehicle with infortainment into a
single OS scares me. A container or two could work here, but now we're talking
about running a container at a priority high enough to linux to fuck off it's
in the middle of something, and the base OS would need to be locked down
decently hard as well to ensure misconfigurations wouldn't bork that dataplane
container.

Really, i'd much rather have it (keep it?) the way airplanes are designed
where the dataplane and control plane for manuevering the vehicle are entirely
separate from any other systems on the vehicle down to at least vlans with
well-defined APIs for the maneuvering system reporting data to less-critical
systems.

------
bregma
I just can't see the Linux kernel ever obtaining ISO 26262 certification at
the ASIL-D level. It would take a special kind of masochist to even consider
doing that.

~~~
thrwyoilarticle
Are you saying this because you think the people contributing to AGL are
unaware of how certification works?

~~~
bregma
I am saying this because I am very intimate with Linux and very intimate with
ISO 26262 certification, but I try to avoid those situations a masochist will
seek out for pleasure. Life is too short.

------
dang
If curious see also this related thread from 2017:
[https://news.ycombinator.com/item?id=15289564](https://news.ycombinator.com/item?id=15289564)

------
darksaints
So sad that Blackberry closed up and effectively killed off QNX. It is the
perfect sort of operating system for things like this.

~~~
theincredulousk
they didn't kill off QNX... It is alive and well as a stand-alone company and
still used in many, many automotive applications

------
dainiusse
If it is going to back as linux desktop -then no. We keep on hearing this is
the year for linux desktop and it never comes. Sadly.

~~~
encom
>We keep on hearing this is the year for linux desktop

No you don't. What you're hearing is this dead horse being constantly dragged
out for another round of beatings. The problem is, nobody has ever defined
what the phrase even means, so it can never be `true´.

------
brobdingnagians
Finally, we can have systemd running our car init!

Just don't name it 0day, or get DoSed...

/s

------
macstuff
I remember Toyota put AGL on the Camry in 2018. Guess what? It was terrible.
The system froze up and crashed all the time. So they finally caved and added
Car Play support. Now their cars all support Android Auto as well.

Great! Now you have AGL in your car. First thing you doing is plug in your
phone for Android Auto or Car Play anyway.

What car companies should focus on is adding things like wireless Car Play and
Android support. Also Car Play supports multiple independent displays, which
no auto manufacturer implements either.

~~~
sircastor
To be clear here, CarPlay is not an OS. CarPlay (as is Android Auto) is an app
that steams an interface to the car’s system.

It’s a replacement interface that runs on your iPhone, but it’s not an
infotainment system. It doesn’t do any of the heavy lifting those systems have
to do to make CarPlay possible.

~~~
macstuff
My bad.

------
throwaway7281
Nice to see Linux in automotive. Recently, Daimler CEO mentioned that they
understand now, that they need an operating system.

Guess what, he said: "think of Windows for cars"

That made me laugh hard. If they do what he says, it will be just another nail
in the coffin of good ol' Daimler.

~~~
2rsf
OS for what ? for the entertainment system Windows might be better, you get
official support and it should be fairly stable since you strip everything
unnecessary from it.

~~~
detaro
Microsoft tried that, and it failed so hard they pretty much pretend it never
existed. That world is ruled by Linux (and sometimes QNX) today.

~~~
jaywalk
The original Ford Sync, which was developed entirely by Microsoft, was great.
Ford decided that they would develop their own UI for the next version on top
of Windows Automotive, and it was an absolute mess. They blamed Microsoft,
switched the OS to QNX and developed an all new UI, which is still a mess to
this day.

I don't think Windows Automotive got a fair shake.

~~~
sanitycheck
MS made a bad situation worse there - they took over version 2 from the
original devs, outsourced maintenance, and pushed back on change requests
assuming Ford would let them build V3 from scratch instead of (painfully)
improving V2. That, as you know, is not what happened!

~~~
jaywalk
Interesting! I didn't know Ford brought Microsoft back on board to try and
rescue the disastrous v2. No surprise that that it didn't work out, though. If
I remember correctly, the UI was Flash and the hardware was vastly
underpowered.

