7 ms·

"Reference applications including media player, tuner, navigation, web browser, Bluetooth, WiFi, HVAC control, audio mixer and vehicle controls" It is nice to

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

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.