18 ms·

Automotive Grade Linux

230 points by known 6y ago

rightbyte 6y ago
"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.)
- panpanna 6y ago
  ECU can mean both engine control unit and electric control unit. The former is a safety critical hard real-time system, the latter can be anything including the widely open "infotainment" system. My understanding is that AGL currently mostly targets infotainment systems.
  - rightbyte 6y ago
    Ye I know ECUs are more than the engine's ECU. I am fine with the car stereo running Linux and getting access to read only CAN data, or at-least with some hardware upstream CAN-filter for what it can send on CAN. Given the auto-update fad that breaks my stuff all the time on my office Win 10 computer (both from MS and the company IT department). I'm not very keen on having over the air updates for ECUs or the Infotainment system. At-least not automatic.
    - rjsw 6y ago
      I did over the air updates of every ECU in a car 20 years ago. This was just a demo at the research lab of the car manufacturer but this has been possible for a fairly long time.
- salicideblock 6y ago
  From my time in the industry, AGL is not even close to considering targeting Engine Control Units. The primary target is infotainment systems. At the time I never heard anyone - not infotainment guys, not ECU, not the Linux geeks - seriously proposing to put Linux there.
  - rightbyte 6y ago
    To be fair they don't seem to want that or use AGL as an ECU OS, ye. However looking at the demo cases they seem to at least to speed control interface with AGL. The quoted list point of vehicle control can get quite broad if car companies are not conservative enough.
    - PinguTS 6y ago
      It is stated there. It is intended for _rapid development of new features_. So it is intended more for prototyping to test new feature and prove points.
- ourlordcaffeine 6y ago
  Nah man python powered ECU is the way it's going to go. The engine stalling whenever the GC runs is a bonus feature.
  - WJW 6y ago
    I know you're joking, but I bet it'd be possible to make a python-powered ECU these days. It's not that hard to make non-allocating code in the first place, but even then the amount of data is so small that a GC cycle could be done in a ms or so at most. An engine running at 3000 RPM is only doing 50 rotations per second, so you have a 20 ms budget to calculate whatever you want, hit whatever spark plug timing you need and then GC.
    - jimktrains2 6y ago
      Engines can turn faster than 3000rpm, even in the general case. Car engines are 4 strokes, so you're probably interested in collecting data and issuing control signals through those 4 strokes. I believe my small car redlines at 7,000rpm, so that leaves roughly 2ms per stroke (for all 4 cylinders). Also, the ECU does more than just the cylinder values, it's monitoring other systems as well, such as the transmission, traction control, &c which also have hard deadlines. I don't think there is enough time to garbage collect, and as other gave stated, there should be little to no need to allocate in this type of code anyway.
    - ben-schaaf 6y ago
      > It's not that hard to make non-allocating code in the first place It sure is in cpython. `a = 1` may need to allocate/reallocate the dict holding the local/global variables. If an integer exceeds 256 or goes below -5 you're getting an allocation for the object - regardless of whether that number has been seen before or not. Of course you can forget about floating point and function calls - maybe even function calls to C functions.
    - rurban 6y ago
      Trivial ECU's run at 500Hz, better ones at 1kHz, the very best (Formula 1) at 10KHz. (fixed typos) There's for sure no dynamic memory, no recursion, only fixed memory slots.
- amelius 6y ago
  It doesn't say how tight the control is, however. There might be a RTOS-based embedded system between the Linux system and the actual vehicle.
  - chromedev 6y ago
    Why not Real Time Linux? https://wiki.linuxfoundation.org/realtime/start https://wiki.linuxfoundation.org/realtime/start
    - formerly_proven 6y ago
      ECUs use "proper" RTOS, where everything is fully static.
- detaro 6y ago
  I'm not sure how you get from "use on vehicle controls" to "they want to put it in the ECU"?
  - jagged-chisel 6y ago
    I understand the difference between “taking control inputs and sending them to the ECU,” but you have to be pretty naive to assume no one goes from “vehicle control” to “engine control unit.”
    - detaro 6y ago
      But if the commenters immediate reaction is "that's a bad idea", then it probably makes sense to assume that's probably not what they mean with the word?
      - michaelt 6y ago
        15 years ago, I'd have laughed if someone predicted we'd see speedometer and entertainment system on single-screen dashboard, as it was 'obvious' there had to be an air gap between them. Just because something once seemed like a bad idea to me, doesn't mean it won't be done - perhaps successfully!
- bpoyner 6y ago
  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 6y ago
    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 6y ago
      A lot of the other stacks are using Qt Quick / QML.
      - throwaway894345 6y ago
        In a past life I built some of these displays with C++/Qt. At the time, QML was still in alpha.
        jschwartzi 6y ago
        You should take a look at QML. It's wonderful.
        throwaway894345 6y ago
        I should take another look at it. Thanks for the reminder.
  - neogodless 6y ago
    On the one hand, MZD-AIO is very cool, and getting Android Auto on my 2015 Mazda 3 is so welcome. On the other hand, with or without Android Auto, my infotainment is wildly unstable, very slow to start (and inconsistently so), and generally sluggish. Starting this spring, Android Auto often crashes out a few seconds in, or if I try to interact with anything (though that could be in part or in whole on the phone side - stock Google Pixel 3...)
- waste_monk 6y ago
  Why? Tesla vehicles run a Linux based OS (iirc it's a derivative of Ubuntu) to do exactly that. We're not talking about engine management or anything real-time/safety critical (I hope!), but things like controlling media playback or sending a request to whatever controls lighting to turn on the cabin lights when you press a button on the touchscreen are totally fine.
- deleted 6y ago
  [deleted]
- geofft 6y ago
  Not that I disagree per se, but why does "containing malloc" mean "complicated"? I'm a lot more confident in 50 lines of well-written C that uses the heap than 500 lines of custom assembly that cleverly reuses the same static memory region for multiple purposes.
  - ncmncm 6y ago
    "Complicated" meaning there is no certainty to how long it will take, or even whether it will succeed at all. Nobody uses assembly code if they can avoid it. But the machine instructions that implement the code are known and unchanging. And nobody re-uses that memory for different things at different times, if there is enough for each use to have its own. Which there always is, nowadays.
- MisterTea 6y ago
  > but I am suspicious of any ECU containing malloc. The sane thing to do when using a general purpose OS as an RTOS, you pre-allocate memory during an init phase then run the control loop as if statically allocated. An ECU (or any tight control loop really) should have ZERO need to dynamically allocate memory while running.
- zxcvbn4038 6y ago
  ECUs have very strict timing requirements that would be unsuitable for a general purpose time share system. Linux would be more for guidance and entertainment. You wouldn’t want a malformed mp3 to cause catastrophic engine failure. You would isolate the two systems completely. Likewise something like auto pilot would sit above the ECU and be isolated from anything accepting user data for the same reason - you need hard deadlines for the various navigation functions to operate within - not as tight as the ECU where you are counting click ticks but much more strict then typical general purpose OS.
- rurban 6y ago
  I think I know actually ECU's running on linux. Not only the Spaceshuttle ran it's "ECU" with 3 dSpace RTLinux controllers. Also the standard Formula 1 ECU by McLaren Applied Technology (Woking UK) runs on that. They also supply the ECU's for NASCAR, IndyCar and Formula-E. Based on the very same technology, dSpace RT. The main reason are the fast MMU IO drivers available for the IO boards, like the 1GB network card or firewire. You dont want to write those drivers. The OS itself is quite trivial compared to that. That's why they use the antique and insecure design of Linux, compared to a modern, small microkernel. https://www.mclaren.com/applied/case-study/formula-1-ecu/ https://www.mclaren.com/applied/case-study/formula-1-ecu/ I wrote a C++ cross-compiler for that. And we even linked Fortran BLAS into that. dSpace only supports C, but you really want overloaded ops for matrix calculations and such. There's no malloc, no exceptions, no terminal IO, no HD.
  - formerly_proven 6y ago
    > Not only the Spaceshuttle ran it's "ECU" with 3 dSpace RTLinux controllers. This doesn't make any sense. The SSME 1st gen controllers were from the 60s, the 2nd gen controllers 68k-based and designed in the early 80s. The main avionics were AP-101s, which predate Linux by decades as well.
- sircastor 6y ago
  Having worked on this project, and a handful of features in it, the "vehicle controls" mentioned here are things like putting the convertible top down, or raising/lowering the ride height of the vehicle. It's all higher-level communication down to dedicated systems that directly manage the feature.
adammunich 6y ago
Half the battle is hardware, who's going to make the computers that will run in Alaska, and Mexico, for 20+ years?
- amelius 6y ago
  NASA?
- detaro 6y ago
  The same companies that have made the computers in cars or industrial control systems for the last 10-20 years?
  - olyjohn 6y ago
    More like 35+ years. Honda has had electronic fuel injection systems that used Intel chips at least as far back as 1985.
- kanox 6y ago
  Isn't this mostly an issue for silicon fabrication? CPUs hardened against space radiation environments are based on existing "regular" designs and I'd expect almost no changes in digital logic.
tW4r 6y ago
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.
- detaro 6y ago
  which "proprietary" bits of Qt do you think you'd need? There isn't much that's not LGPL or GPL - and while the safety renderer could have automotive applications, you wouldn't care about it for a DIY entertainment system.
- mschuster91 6y ago
  > 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 6y ago
    Do you have any resources or guides on how to get suspend to ram working?
    - mschuster91 6y ago
      Arch Linux has a decent guide explaining the behind-the-scenes stuff: https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate https://wiki.archlinux.org/index.php/Power_management/Suspen... On desktops and laptops, it Usually Should Just Work (tm). The general culprits for issues are proprietary graphics and wifi drivers as well as shoddy BIOSes with broken ACPI tables, but I never had to dig this deep. For embedded systems, the situation is more complex, as the chipset needs to support it - suspend itself is not the problem in most cases, but wakeup is - for example, the Raspberry Pi does not have a dedicated interrupt (https://github.com/raspberrypi/linux/issues/1281 https://github.com/raspberrypi/linux/issues/1281). If you're working with an embedded chipset, your best bet is the manufacturer, they have to deal with that in the BSP.
bregma 6y ago
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.
- PinguTS 6y ago
  I just can't see that the HMI requires any ASIL-D. ASIL-D is most likely realized by a central ECU who manages state.
- jeffreygoesto 6y ago
  Agreed. SIL2LinuxMP generated more questions than answers, which is very good for a start. But is is discontinued and we'll have to see if elisa takes off or just pokes around in some corners. The problem is, a safety system must be fully understood and then all changes need to be reviewed not to destroy the given guarantees any more. Given the pace of Linux development, this would be a gargantuan endeavor or you'd need to stick with an old and stripped down version that does not have any benefits over a traditional rt os.
- thrwyoilarticle 6y ago
  Are you saying this because you think the people contributing to AGL are unaware of how certification works?
  - bregma 6y ago
    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.
- waiseristy 6y ago
  The general industry consensus right now is to validate it for a higher ASIL level (B) and then wrapping it in an ASIL-D compliant layer.
- caniszczyk 6y ago
  They are trying their best via the ELISA effort: https://elisa.tech https://elisa.tech
throwaway7281 6y ago
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 6y ago
  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 6y ago
    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.
    - pjmlp 6y ago
      Server room is ruled by Linux, on the embedded space there are other better suited RTOS alternatives, alongside the commercial ones, all the beloved FOSS alternatives are MIT/BSD based. And even on server room, thanks to cloud, managed runtimes and servless, Linux's relevance is going to don't matter in the upcoming decade.
      - detaro 6y ago
        The specific context mentioned was integrated entertainment systems in cars, and no, there are no "better suited RTOS alternatives" in common use there. It's Linux or QNX. Your generic talking points about Linux in other fields are completely irrelevant for that.
        pjmlp 6y ago
        Fair enough, then I would point out to the bare metal Qt deployments and Android as well (which the Linux kernel is an implementation detail for the Java and ISO C userspace).
morganvachon 6y ago
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 6y ago
  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).
  - throWaythxMod 6y ago
    I am surprised to see this posted here. Among the general population, people think adding features is easy, but I'd expect people on HN would understand tech debt. Maybe they don't understand automotive is old. There is more tech debt than you can imagine.
    - q3k 6y ago
      I understand tech debt. But you can't just handwave all tech debt as 'it just happens, get used to it'. It's debt. You're supposed to pay it back at some point, and automotive/industrial/embedded is really, really bad at it, forever stuck in a 'it works, ship it' mentality. If you're never paying back your tech debt, it's not tech debt. It's just poor software engineering practices.
lmilcin 6y ago
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.
- nabla9 6y ago
  Automotive grade Linux is not controlling the car. AGL targets infotainment systems and other aspects. It can have access to more important data but it's not controlling the car.
  - lmilcin 6y ago
    There was a bunch of attempts at this and I even have passing experience working with Intel guys on their IVI project which was integrated into AGL (https://wiki.tizen.org/IVI https://wiki.tizen.org/IVI). I don't know what makes the people think this will work this time when it did not previously. I just know that it previously was restricted to infotainment even in its name and mission statement and now that does not seem to be true any longer. "Automotive Grade Linux is a collaborative open source project that is bringing together automakers, suppliers and technology companies to accelerate the development and adoption of a fully open software stack for the connected car. With Linux at its core, AGL is developing an open platform from the ground up that can serve as the de facto industry standard to enable rapid development of new features and technologies." See, nowhere it mentions this is for infotainment only.
dainiusse 6y ago
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 6y ago
  >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´.
- yjftsjthsd-h 6y ago
  > We keep on hearing this is the year for linux desktop and it never comes. Sadly. "The future is already here — it's just not very evenly distributed." The year of the Linux desktop was a decade ago, and it remains perfectly usable.
- pjmlp 6y ago
  How can it ever come, when the few desktops that could provide a full stack developer experience are ostracized in name of having 2020 computers replicating PDP-11s like I used to do in 1993? Naturally the only ones that succeeded at it only rely on the Linux kernel as an implementation detail, and could actually use any POSIX like kernel.
macstuff 6y ago
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 6y ago
  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 6y ago
    My bad.
brobdingnagians 6y ago
Finally, we can have systemd running our car init! Just don't name it 0day, or get DoSed... /s
trishankdatadog 6y ago
"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/reference/security/part-8/1-FOTA.html https://docs.automotivelinux.org/docs/en/master/architecture...
crb002 6y ago
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-automation/ https://www.froglogic.com/squish/editions/qt-gui-test-automa... - 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.
dang 6y ago
If curious see also this related thread from 2017: https://news.ycombinator.com/item?id=15289564 https://news.ycombinator.com/item?id=15289564
darksaints 6y ago
So sad that Blackberry closed up and effectively killed off QNX. It is the perfect sort of operating system for things like this.
- theincredulousk 6y ago
  they didn't kill off QNX... It is alive and well as a stand-alone company and still used in many, many automotive applications
joshAg 6y ago
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.

230 points by known 6y ago

"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.)

panpanna 6y ago
ECU can mean both engine control unit and electric control unit. The former is a safety critical hard real-time system, the latter can be anything including the widely open "infotainment" system. My understanding is that AGL currently mostly targets infotainment systems.
- rightbyte 6y ago
  Ye I know ECUs are more than the engine's ECU. I am fine with the car stereo running Linux and getting access to read only CAN data, or at-least with some hardware upstream CAN-filter for what it can send on CAN. Given the auto-update fad that breaks my stuff all the time on my office Win 10 computer (both from MS and the company IT department). I'm not very keen on having over the air updates for ECUs or the Infotainment system. At-least not automatic.
  - rjsw 6y ago
    I did over the air updates of every ECU in a car 20 years ago. This was just a demo at the research lab of the car manufacturer but this has been possible for a fairly long time.
salicideblock 6y ago
From my time in the industry, AGL is not even close to considering targeting Engine Control Units. The primary target is infotainment systems. At the time I never heard anyone - not infotainment guys, not ECU, not the Linux geeks - seriously proposing to put Linux there.
- rightbyte 6y ago
  To be fair they don't seem to want that or use AGL as an ECU OS, ye. However looking at the demo cases they seem to at least to speed control interface with AGL. The quoted list point of vehicle control can get quite broad if car companies are not conservative enough.
  - PinguTS 6y ago
    It is stated there. It is intended for _rapid development of new features_. So it is intended more for prototyping to test new feature and prove points.
ourlordcaffeine 6y ago
Nah man python powered ECU is the way it's going to go. The engine stalling whenever the GC runs is a bonus feature.
- WJW 6y ago
  I know you're joking, but I bet it'd be possible to make a python-powered ECU these days. It's not that hard to make non-allocating code in the first place, but even then the amount of data is so small that a GC cycle could be done in a ms or so at most. An engine running at 3000 RPM is only doing 50 rotations per second, so you have a 20 ms budget to calculate whatever you want, hit whatever spark plug timing you need and then GC.
  - jimktrains2 6y ago
    Engines can turn faster than 3000rpm, even in the general case. Car engines are 4 strokes, so you're probably interested in collecting data and issuing control signals through those 4 strokes. I believe my small car redlines at 7,000rpm, so that leaves roughly 2ms per stroke (for all 4 cylinders). Also, the ECU does more than just the cylinder values, it's monitoring other systems as well, such as the transmission, traction control, &c which also have hard deadlines. I don't think there is enough time to garbage collect, and as other gave stated, there should be little to no need to allocate in this type of code anyway.
  - ben-schaaf 6y ago
    > It's not that hard to make non-allocating code in the first place It sure is in cpython. `a = 1` may need to allocate/reallocate the dict holding the local/global variables. If an integer exceeds 256 or goes below -5 you're getting an allocation for the object - regardless of whether that number has been seen before or not. Of course you can forget about floating point and function calls - maybe even function calls to C functions.
  - rurban 6y ago
    Trivial ECU's run at 500Hz, better ones at 1kHz, the very best (Formula 1) at 10KHz. (fixed typos) There's for sure no dynamic memory, no recursion, only fixed memory slots.
amelius 6y ago
It doesn't say how tight the control is, however. There might be a RTOS-based embedded system between the Linux system and the actual vehicle.
- chromedev 6y ago
  Why not Real Time Linux? https://wiki.linuxfoundation.org/realtime/start https://wiki.linuxfoundation.org/realtime/start
  - formerly_proven 6y ago
    ECUs use "proper" RTOS, where everything is fully static.
detaro 6y ago
I'm not sure how you get from "use on vehicle controls" to "they want to put it in the ECU"?
- jagged-chisel 6y ago
  I understand the difference between “taking control inputs and sending them to the ECU,” but you have to be pretty naive to assume no one goes from “vehicle control” to “engine control unit.”
  - detaro 6y ago
    But if the commenters immediate reaction is "that's a bad idea", then it probably makes sense to assume that's probably not what they mean with the word?
    - michaelt 6y ago
      15 years ago, I'd have laughed if someone predicted we'd see speedometer and entertainment system on single-screen dashboard, as it was 'obvious' there had to be an air gap between them. Just because something once seemed like a bad idea to me, doesn't mean it won't be done - perhaps successfully!
bpoyner 6y ago
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 6y ago
  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 6y ago
    A lot of the other stacks are using Qt Quick / QML.
    - throwaway894345 6y ago
      In a past life I built some of these displays with C++/Qt. At the time, QML was still in alpha.
      - jschwartzi 6y ago
        You should take a look at QML. It's wonderful.
        throwaway894345 6y ago
        I should take another look at it. Thanks for the reminder.
- neogodless 6y ago
  On the one hand, MZD-AIO is very cool, and getting Android Auto on my 2015 Mazda 3 is so welcome. On the other hand, with or without Android Auto, my infotainment is wildly unstable, very slow to start (and inconsistently so), and generally sluggish. Starting this spring, Android Auto often crashes out a few seconds in, or if I try to interact with anything (though that could be in part or in whole on the phone side - stock Google Pixel 3...)
waste_monk 6y ago
Why? Tesla vehicles run a Linux based OS (iirc it's a derivative of Ubuntu) to do exactly that. We're not talking about engine management or anything real-time/safety critical (I hope!), but things like controlling media playback or sending a request to whatever controls lighting to turn on the cabin lights when you press a button on the touchscreen are totally fine.
deleted 6y ago
[deleted]
geofft 6y ago
Not that I disagree per se, but why does "containing malloc" mean "complicated"? I'm a lot more confident in 50 lines of well-written C that uses the heap than 500 lines of custom assembly that cleverly reuses the same static memory region for multiple purposes.
- ncmncm 6y ago
  "Complicated" meaning there is no certainty to how long it will take, or even whether it will succeed at all. Nobody uses assembly code if they can avoid it. But the machine instructions that implement the code are known and unchanging. And nobody re-uses that memory for different things at different times, if there is enough for each use to have its own. Which there always is, nowadays.
MisterTea 6y ago
> but I am suspicious of any ECU containing malloc. The sane thing to do when using a general purpose OS as an RTOS, you pre-allocate memory during an init phase then run the control loop as if statically allocated. An ECU (or any tight control loop really) should have ZERO need to dynamically allocate memory while running.
zxcvbn4038 6y ago
ECUs have very strict timing requirements that would be unsuitable for a general purpose time share system. Linux would be more for guidance and entertainment. You wouldn’t want a malformed mp3 to cause catastrophic engine failure. You would isolate the two systems completely. Likewise something like auto pilot would sit above the ECU and be isolated from anything accepting user data for the same reason - you need hard deadlines for the various navigation functions to operate within - not as tight as the ECU where you are counting click ticks but much more strict then typical general purpose OS.
rurban 6y ago
I think I know actually ECU's running on linux. Not only the Spaceshuttle ran it's "ECU" with 3 dSpace RTLinux controllers. Also the standard Formula 1 ECU by McLaren Applied Technology (Woking UK) runs on that. They also supply the ECU's for NASCAR, IndyCar and Formula-E. Based on the very same technology, dSpace RT. The main reason are the fast MMU IO drivers available for the IO boards, like the 1GB network card or firewire. You dont want to write those drivers. The OS itself is quite trivial compared to that. That's why they use the antique and insecure design of Linux, compared to a modern, small microkernel. https://www.mclaren.com/applied/case-study/formula-1-ecu/ https://www.mclaren.com/applied/case-study/formula-1-ecu/ I wrote a C++ cross-compiler for that. And we even linked Fortran BLAS into that. dSpace only supports C, but you really want overloaded ops for matrix calculations and such. There's no malloc, no exceptions, no terminal IO, no HD.
- formerly_proven 6y ago
  > Not only the Spaceshuttle ran it's "ECU" with 3 dSpace RTLinux controllers. This doesn't make any sense. The SSME 1st gen controllers were from the 60s, the 2nd gen controllers 68k-based and designed in the early 80s. The main avionics were AP-101s, which predate Linux by decades as well.
sircastor 6y ago
Having worked on this project, and a handful of features in it, the "vehicle controls" mentioned here are things like putting the convertible top down, or raising/lowering the ride height of the vehicle. It's all higher-level communication down to dedicated systems that directly manage the feature.

adammunich 6y ago

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

amelius 6y ago
NASA?
detaro 6y ago
The same companies that have made the computers in cars or industrial control systems for the last 10-20 years?
- olyjohn 6y ago
  More like 35+ years. Honda has had electronic fuel injection systems that used Intel chips at least as far back as 1985.
kanox 6y ago
Isn't this mostly an issue for silicon fabrication? CPUs hardened against space radiation environments are based on existing "regular" designs and I'd expect almost no changes in digital logic.

tW4r 6y ago

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.

detaro 6y ago
which "proprietary" bits of Qt do you think you'd need? There isn't much that's not LGPL or GPL - and while the safety renderer could have automotive applications, you wouldn't care about it for a DIY entertainment system.
mschuster91 6y ago
> 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 6y ago
  Do you have any resources or guides on how to get suspend to ram working?
  - mschuster91 6y ago
    Arch Linux has a decent guide explaining the behind-the-scenes stuff: https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate https://wiki.archlinux.org/index.php/Power_management/Suspen... On desktops and laptops, it Usually Should Just Work (tm). The general culprits for issues are proprietary graphics and wifi drivers as well as shoddy BIOSes with broken ACPI tables, but I never had to dig this deep. For embedded systems, the situation is more complex, as the chipset needs to support it - suspend itself is not the problem in most cases, but wakeup is - for example, the Raspberry Pi does not have a dedicated interrupt (https://github.com/raspberrypi/linux/issues/1281 https://github.com/raspberrypi/linux/issues/1281). If you're working with an embedded chipset, your best bet is the manufacturer, they have to deal with that in the BSP.

bregma 6y ago

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.

PinguTS 6y ago
I just can't see that the HMI requires any ASIL-D. ASIL-D is most likely realized by a central ECU who manages state.
jeffreygoesto 6y ago
Agreed. SIL2LinuxMP generated more questions than answers, which is very good for a start. But is is discontinued and we'll have to see if elisa takes off or just pokes around in some corners. The problem is, a safety system must be fully understood and then all changes need to be reviewed not to destroy the given guarantees any more. Given the pace of Linux development, this would be a gargantuan endeavor or you'd need to stick with an old and stripped down version that does not have any benefits over a traditional rt os.
thrwyoilarticle 6y ago
Are you saying this because you think the people contributing to AGL are unaware of how certification works?
- bregma 6y ago
  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.
waiseristy 6y ago
The general industry consensus right now is to validate it for a higher ASIL level (B) and then wrapping it in an ASIL-D compliant layer.
caniszczyk 6y ago
They are trying their best via the ELISA effort: https://elisa.tech https://elisa.tech

throwaway7281 6y ago

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 6y ago
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 6y ago
  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.
  - pjmlp 6y ago
    Server room is ruled by Linux, on the embedded space there are other better suited RTOS alternatives, alongside the commercial ones, all the beloved FOSS alternatives are MIT/BSD based. And even on server room, thanks to cloud, managed runtimes and servless, Linux's relevance is going to don't matter in the upcoming decade.
    - detaro 6y ago
      The specific context mentioned was integrated entertainment systems in cars, and no, there are no "better suited RTOS alternatives" in common use there. It's Linux or QNX. Your generic talking points about Linux in other fields are completely irrelevant for that.
      - pjmlp 6y ago
        Fair enough, then I would point out to the bare metal Qt deployments and Android as well (which the Linux kernel is an implementation detail for the Java and ISO C userspace).

morganvachon 6y ago

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 6y ago
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).
- throWaythxMod 6y ago
  I am surprised to see this posted here. Among the general population, people think adding features is easy, but I'd expect people on HN would understand tech debt. Maybe they don't understand automotive is old. There is more tech debt than you can imagine.
  - q3k 6y ago
    I understand tech debt. But you can't just handwave all tech debt as 'it just happens, get used to it'. It's debt. You're supposed to pay it back at some point, and automotive/industrial/embedded is really, really bad at it, forever stuck in a 'it works, ship it' mentality. If you're never paying back your tech debt, it's not tech debt. It's just poor software engineering practices.

lmilcin 6y ago

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.

nabla9 6y ago
Automotive grade Linux is not controlling the car. AGL targets infotainment systems and other aspects. It can have access to more important data but it's not controlling the car.
- lmilcin 6y ago
  There was a bunch of attempts at this and I even have passing experience working with Intel guys on their IVI project which was integrated into AGL (https://wiki.tizen.org/IVI https://wiki.tizen.org/IVI). I don't know what makes the people think this will work this time when it did not previously. I just know that it previously was restricted to infotainment even in its name and mission statement and now that does not seem to be true any longer. "Automotive Grade Linux is a collaborative open source project that is bringing together automakers, suppliers and technology companies to accelerate the development and adoption of a fully open software stack for the connected car. With Linux at its core, AGL is developing an open platform from the ground up that can serve as the de facto industry standard to enable rapid development of new features and technologies." See, nowhere it mentions this is for infotainment only.

dainiusse 6y ago

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 6y ago
>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´.
yjftsjthsd-h 6y ago
> We keep on hearing this is the year for linux desktop and it never comes. Sadly. "The future is already here — it's just not very evenly distributed." The year of the Linux desktop was a decade ago, and it remains perfectly usable.
pjmlp 6y ago
How can it ever come, when the few desktops that could provide a full stack developer experience are ostracized in name of having 2020 computers replicating PDP-11s like I used to do in 1993? Naturally the only ones that succeeded at it only rely on the Linux kernel as an implementation detail, and could actually use any POSIX like kernel.

macstuff 6y ago

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 6y ago
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 6y ago
  My bad.

brobdingnagians 6y ago

Finally, we can have systemd running our car init! Just don't name it 0day, or get DoSed... /s

trishankdatadog 6y ago

"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/reference/security/part-8/1-FOTA.html https://docs.automotivelinux.org/docs/en/master/architecture...

crb002 6y ago

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-automation/ https://www.froglogic.com/squish/editions/qt-gui-test-automa... - 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.

dang 6y ago

If curious see also this related thread from 2017: https://news.ycombinator.com/item?id=15289564 https://news.ycombinator.com/item?id=15289564

darksaints 6y ago

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

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

joshAg 6y ago

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.