Hi everyone, small disclaimer, I am the CEO of OxidOS. OxidOS is basically Tock OS + Certification Documents + Tests and some proprietary drivers (which our clients do not agree to publish into open source). We try to submit into upstream any changes that we need to make to Tock OS to make it better suited for the safety critical market and regularly pull new changes (as much as possible due to certification reasons). Just look at the CAN support, Ethernet support (in progress) and many other PRs that our team has sent.

We work closely with the Tock OS' core working group, me being one of its members.

Please feel free to reach out if you have any questions related to this.

Are you targeting both ICE and EV's vehicles?

In short - both, depending on the clients :)

The actual open source OS (OxidOS is proprietary): https://tockos.org/

They're pretty open about that in fairness. Doesn't look like there's any overlap between the TockOS developers and this team.

Hi! This is Daniel from OxidOS Automotive (stating this for disclaimer purposes).

Yes, our OS is based on TockOS, and our CEO (Alexandru Radovici) is #7 in the contributors list (https://github.com/tock/tock/graphs/contributors), with other colleagues contributing in the past years. Of course, we also push anything that we fix / that is useful for the general Tockos community upstream.

I don't think that's fair. They explicitly name Tock in literally the second sentence on their front page.

I'm not sure what you mean about OxidOS not being the OS? It's still an OS even if it is heavily based on an existing OS. Is Android not an OS? Fuchsia?

> I'm not sure what you mean about OxidOS not being the OS?

Meaning, it's sort of "GEOS" in that although it has "OS" in the name, it sits on top of the "real" OS. Tock is apparently its "native" kernel/OS, but it can also sit on QNX and Linux in the form of a Wasm runtime.

Android is an OS that uses a heavily-customized Linux kernel.

The definition of OS is not as strict as you are imagining. You could equally say Android sits on top of the "real" Linux OS.

"But Linux is just a kernel, not an OS!"

Oh so is FreeRTOS not an OS? What about the "Little Kernel Embedded OS"?

You're nitpicking imaginary definitions.

Fuschia literally is a ground-up OS with its own kernel (your point is well-made with regards to Android though)

Fuchsia's kernel is based on the Little Kernel embedded OS.

https://github.com/littlekernel/lk

I am always excited to hear about new operating systems because we desperately need to move on from where we are stuck now.

Just the other day we had several stories about a new interesting operating system DBOS that was closed source proprietary for profit.

This also seems to be closed source proprietary for profit.

Nothing inherently wrong with it, but I wish i could play with them at home. Opens sourced operating systems seem t obe losing ground.

For those wanting to go beyond hobbyist, talking to a company of your aligned interests in their product often magically provides you with their SDK or facilities. With the dispersed world wide development these days, that can add some complication to this formula.

For a layperson, is this just for older style ECUs controlling various car functions, instead of e.g. electronic dashboards?

Basically, will this be also usable for more modern vehicles (say 2015+) that have been highly digitized, or is the project scope much smaller?

My understanding is that beyond the rise of EVs, the longevity of vehicles of the last decades is in question as they use more and more computerised controls, and their parts becoming rarer on top of the proprietary software controls. So beyond replacing just the ECU, keeping modern cars alive as they age and even become classics is a valuable task.

I believe the concerns of the digital era losing historicity due to the ease of bitrot translate to vehicles as well.

It won't be something you as a layperson can just take and run in your car, like you would Linux on an old laptop. The HW is pretty diverse and is tightly coupled with the car. It's more like something car makers can use to build on top of in order to quickly and safely bring up an ECU. People who worked with, for example, AUTOSAR stacks on modern ECU's know how much of a pain bringing up even just CAN communication can be.

I share your concern about bitrot and longevity in modern cars, and this could help, but it would still not be something someone could just do in their garage, you'd likely need more resources than that.

Yes, new cars are evolving in terms of ECU architecture, and we are targeting small chips for two use cases:

First - as "edge components" get smarter - you still have small microcontrollers all over the car (for example - you need a local MCU and a complex PCB for running a headlight with dozens of LEDs with minimum wiring to a central command unit);

Secondly - you now have multi-core, multi-arhitecture controllers - and you need small OSs for some of these cores in order to run embedded apps efficiently.

Rust is certainly an attractive option, but the support for MCUs used in automotive seems weak (because the variety of LLVM backends is less than that of gcc). What do you think about this? Will you use a GCC-based Rust compiler (e.g. gccrs or rustc_codegen_gcc) or your own LLVM backend?

I’m not in automotive, but I am interested in this too. Which MCUs are you thinking of?

Not OP, but just a set of MCU arch common in automotive that you'd have to bend a bit to compile Rust for:

- Renesas RH 850/v850 - there is a gcc but not a llvm backend

- RL78 (I think this is kind of dieing though)

- Infineon Aurix Tricore (Hightec has a compiler for it)

- PowerPC was pretty popular but I did not see it that much lately.

I'd like to add ST's Stellar MCU's: https://www.st.com/en/automotive-microcontrollers/stellar-32...

Looks like Oxid has a demo using these proc's: https://www.linkedin.com/feed/update/urn:li:activity:7041723...

We did have a demo using the Stellar MCU's. :)

But they weren't on my list because those have ARM cores and the support for those in Rust is quite good.

Thanks! Always interested in digging into details :)

There’s been a tremendous amount of interest in Rust for automotive over the past few years, but it’s a hard world to learn about unless you’re in it.

I think this is for component manufacturers, a bit like Arduino IDE for windshield wipers and left front blinker circuits.

Reflashing automotive ECU with open source firmware isn’t going to make a lot of sense, many still use OTP ROMs and even sometimes real hardwired ROMs.

They might be able to find a niche in industrial equipment. But for regular cars it will be hard to compete with QNX.

Disclaimer: I work at OxidOs.

Regular cars have a lot of OS'es in them that are not QNX. I'd say OSEK derived OS'es are much more common than QNX. And I believe there is quite a bit of space for alternatives.

You’re right, they do have lots of OSes. But most of them are for lower-ASIL elements where the functional safety and SOTIF requirements are less strict. I’d be very surprised if there was quite as much diversity at ASIL D.

Edit: Usually good form to point out your affiliation when you're commenting on your own company's announcements. Unless I'm very much mistaken, RadVl sounds a lot like a portmanteau of Vlad Radulescu, FSM at OxidOS. It's a great looking product, don't get me wrong!

There are 2 ASIL-D OSEK implementations off the top of my head, Tasking, the EB one ( I think they actually have _2_ variants here, the normal one and a microkernel) and I'm sure there are others, these being just the ones I saw on projects I worked on before Oxidos.

I'm sure Vector has one as well.

Edit: You are right, that was poor form, I added the disclaimer.

"Written in Rust" is quickly turning into the programming equivalent of "This web site is secure" badge.

Yes, Rust can eliminate a significant portion of memory-safety related bugs. But it doesn't eliminate all bugs, or all security bugs, or all memory-safety related bugs for that matter.

We need better metrics for safety than "Manufactured in Sweden" of programming in marketing copy. Perhaps certifications and compliance programs similar to FCC, TUV. Maybe like PCI but with an expanded scope.

It's only a matter of time a significant memory-safety related vulnerability is found in a Rust program and everyone will start saying "see? Rust has as many safety problems as C" and use it as an excuse not to use it if we lean too much on "Rust = safety" false equivalence.

We already have that. It is the Common Criteria for Information Technology Security Evaluation, ISO 15408. Most large software developers already certify products against it such as Windows [1], iOS [2], Android, Linux, etc. It is the primary certification presented in "About Security" and "Certification" pages by almost every company if they have any certifications at all.

The thing is that they all certify at the lowest possible levels which certify that the systems ensure no meaningful security because they are unable to certify the presence of any meaningful security in those products even after decades of attempts. You do not establish any audited security until you reach a level comparable to EAL5, and most companies opt for EAL1 with all of the big names maxing out at EAL4 historically. For some reason, people are happy using products that are certified to be insecure and inadequate which is why we are in this insecure hellscape.

[1] https://learn.microsoft.com/en-us/windows/security/security-...

[2] https://support.apple.com/en-my/guide/certifications/apc3fa9...

I didn’t know about ISO 15408, but as I understand from what you say, that isn’t broad or comprehensive enough to be widely used.

The Common Criteria is broadly and comprehensively used and covers most major product categories. There is no product security standard more widely used and internationally accepted and most major vendors already certify against it.

It is just that they all certify at the lowest levels of compliance because they are incapable of doing better. To compare against PCI DSS, it is like everybody is compliant… at Level 4. Or like having a certified apprentice electrician wiring up your substation. It is obviously wrong and inadequate, but people have been convinced to have warm fuzzy feelings when they see the word certified no matter how low of a certification level was chosen.

It is why everything gets hacked all the time, everybody is deploying systems that are certified insecure and inadequate for their operating environment.

When it says "based on open source" does that mean that they used open-source tools (in part) to build a close sourced proprietary operating system?

As far as I can tell from their website, this isn’t related to Oxide Computer and I’d guess there’s going to be a cease and desist real soon now.

You're right that the names are similar, but we aren't litigious like that. This is a different thing, even though it has a similar name. This isn't the first time I'm hearing about this OS :)

Heck, there's even Oxidize, a Rust conference for embedded/industrial Rust users.

Nobody would reasonably confuse these products.

And just to further agree: there is no attempt here from the OxidOS folks to confuse folks or to otherwise conflate their work with ours. So certainly no C&D coming from us -- it's good to see more Rust-based systems in the world! (Though I do wish it were entirely open source!)

Based in Romania might make that hard to do

Until they try to expand outside the Romanian car market…

> 100 Times safer cars

I wish companies would back up numbers like this. Are they really going to reduce the number of accidents on the road by a factor of 100 due to a better os? I really struggle to believe that.

If they had to back it up then they would not be able to say it. Are you really trying to infringe on their rights to endanger lives by fraudulently claiming suitability for safety-critical applications without any evidence beyond their imaginations?

If we demanded evidence from everybody then people would not be able to sell their sub-standard and inadequate systems. Think about how much less money they would make, or god forbid go out of business, if we demanded evidence before risking human lives. No, better to just let them make unqualified, extremely strong claims with no supporting evidence or audit to protect their business. I mean, it is what we let every other company like Microsoft, Apple, and Google do, so why not?

What is the unit of measure for "safeness," anyway? And how will we know if they reach 101 "safety units?"

it may be about safety against cyberattacks

I can’t think of a single case of cyberattacks against cars. Do you know of any?

Is this written in Rust by any chance?

the site says "100 Times safer cars", so yes, as rust makes everything automatically safer.

I know quite a few people that would prefer not having rust in their cars.

After build you have bare metal, no rust remains.

For what reasons?

It is unsightly and structurally unsound.

Because they want their car without software... ;-)

It's nice to have a software for entertainment... but it takes more trust to have some software controlled brakes

Yes its very oxidised