Two Routes to Automotive Rust
OxidOS and Veecle as complementary automotive platforms around Ferrocene
The comparison is most useful when it begins with software layers rather than vendor labels. Ferrocene is the qualified Rust compiler toolchain and its assurance material. OxidOS is a Rust-based secure operating-system ecosystem for constrained automotive controllers. Veecle is a runtime, service framework and development workflow that can operate over several existing environments. They answer different parts of a safety argument and can serve different programs inside the same OEM or Tier 1.
The decision is therefore not “which Rust product wins?” It is whether a program needs an incremental bridge over a legacy estate, or a greenfield safety-oriented foundation. Veecle is the stronger route for preserving existing assets while introducing portable Rust services. OxidOS is the cleaner route when kernel, isolation and applications can be shaped together from the outset. Ferrocene anchors the tool-confidence case wherever its qualified target scope matches the deployment.
| Layer | Primary responsibility | Representative product |
|---|---|---|
| Development toolchain | Translate and validate Rust source; provide qualification evidence and safety guidance. | Ferrocene Compiler distribution, qualified targets, manuals and supporting evidence. |
| OS / kernel | Scheduling, hardware mediation, memory separation and execution environment. | OxidOS Rust kernel and user space with independently compiled sandboxed applications. |
| Runtime / middleware | Services, communication abstractions, deployment portability and integration workflow. | Veecle Vehicle software runtime and tooling across selected OS and hardware environments. |
| Vehicle item | Programme architecture, hazards, requirements, integration, verification and final safety case. | OEM / Tier 1 / integrator No lower-layer certificate replaces this responsibility. |
Figure 1. The three products occupy different layers; the vehicle item remains a programme responsibility.
A two-track architecture is more credible than forcing one platform across every controller. It also gives an engineering partner a useful role: maintaining traceability from compiler assumptions through platform configuration to application evidence, and selecting a qualified toolchain per target rather than treating Rust support as a universal certification claim.
Ferrocene defines the toolchain boundary
Ferrocene is a downstream distribution of the Rust compiler maintained by Ferrous Systems for high-assurance use. Its public repository describes qualification under ISO 26262, IEC 61508 and IEC 62304. The public target manual is the more important document for project planning: qualification applies to stated releases, host/target combinations and operating assumptions, not to every architecture supported by upstream Rust.
The public development-branch manual lists bare-metal Armv8-A, Armv7-R and Armv7E-M targets, plus x86-64 Linux, at the Qualified level. Other targets are grouped separately as Quality Managed, Supported or Experimental. Those labels are operationally significant: Supported is not Qualified, and a preview on the main documentation branch should still be reconciled with the exact customer release documentation before a program baseline is frozen.
| Claim | What the public evidence supports | What it does not mean |
|---|---|---|
| Compiler qualified to ISO 26262 ASIL D | The toolchain may be used under its safety manual and qualified target conditions in development up to the stated integrity level. | The resulting ECU, application, OS or every Rust library is automatically certified. |
| Certified core subset | A defined subset is certified to ISO 26262 ASIL B and IEC 61508 SIL 2 on qualified targets. | All of core, alloc, std or third-party crates are inside the library certificate. |
| Open source and upstream-compatible | Source, procedures and qualification-oriented materials can be inspected; ordinary Rust workflows remain familiar. | A self-built binary necessarily carries the same commercial validation, support or signed evidence as a supplied release. |
Table 1. “Qualified,” “certified” and “certifiable” describe different objects and scopes.
Library scope is the common trap. Ferrocene’s manual states that end-use of uncertified parts of core, and of alloc, std, test and proc_macro, remains outside the current library-certification scope. The compiler evaluates and tests those libraries for compiler qualification, but that is not the same as certifying their use in an end product. A safety plan should therefore freeze the certified subset, use call-graph or equivalent evidence to police it, and document any deviations.
Both OxidOS and Veecle ultimately become binaries. A qualified compiler removes one major tool-confidence gap and supplies a stable evidence interface for local integration work. Its value is greatest when target, release, options and libraries are mapped explicitly to the platform configuration—not when “Rust is safe” is used as a blanket claim.
Veecle for incremental and mixed-estate migration
Veecle’s positioning is strongest above the OS boundary. Its Development Studio white paper describes a repeatable workflow from modeling through simulation and mocking, CI, hardware deployment and safety migration. Application logic can be developed away from final hardware, while the runtime or execution environment is selected later. The paper names AUTOSAR-based and lightweight FreeRTOS arrangements and a migration path that includes SafeRTOS, PXROS-HR, AUTOSAR and QNX.
This approach addresses the practical constraint that validated C and C++ assets cannot be rewritten all at once. Rust services can be introduced behind explicit interfaces, exercised in simulation, and deployed on target when the hardware and drivers are ready. The resulting safety case still has to cover FFI contracts, scheduling assumptions, generated configuration, transport semantics and failure propagation. Rust narrows some fault classes; it does not erase the integration boundary.
| Existing C / C++ assets | Explicit bridge and contracts | Rust vehicle services | Selectable runtime / OS |
|---|---|---|---|
| Drivers, diagnostics, legacy application logic | FFI, serialization, ownership, timing and error mapping | Portable services developed with simulation and CI | FreeRTOS / SafeRTOS / PXROS-HR / AUTOSAR / QNX |
Figure 2. Veecle’s migration pattern preserves assets while making the C/Rust boundary explicit.
AURIX is the essential target caveat. Infineon’s published AURIX Rust ecosystem combines its PAC, Bluewind drivers, Veecle NOS, PXROS-HR and HighTec’s ISO 26262 ASIL D qualified Rust compiler for TC3x and TC4x. That is a concrete, credible route for TriCore. It is not evidence that Ferrocene is qualified for TriCore: TriCore does not appear in Ferrocene’s current public qualified-target list.
| Programme situation | Recommended reading | Toolchain implication |
|---|---|---|
| AURIX TC3x / TC4x safety ECU | Veecle NOS and PXROS-HR provide a documented Rust runtime path alongside legacy code. | Use the HighTec qualified Rust compiler unless a different qualified scope is contractually established. |
| Qualified Arm controller | Veecle can support the incremental architecture where its runtime and platform port meet programme needs. | Ferrocene is plausible when the exact Arm tuple and release are Qualified. |
| HPC / QNX or Linux environment | The hardware-independent service model is relevant, but runtime and target claims require release-specific confirmation. | Check whether the target is Qualified, Quality Managed or merely Supported in the selected Ferrocene release. |
Table 3. Toolchain selection follows the target, not the portfolio narrative.
Table 2. Toolchain selection follows the target, not the portfolio narrative.
Best fit. Ferrocene plus Veecle is a compelling editorial shorthand for Arm-based incremental migration, but it is not a universal bundle. Its strongest customer is an OEM or Tier 1 with substantial existing software, multiple target families and a need to add Rust functions without turning every program into a platform rewrite.
OxidOS for a greenfield safety architecture
OxidOS describes an industrial platform built on Tock: a Rust-based kernel, separated user space and independently compiled memory-sandboxed applications. It also describes cryptographic credentials, digital signing and mediated hardware access. These mechanisms are relevant to freedom-from-interference and containment arguments, especially on controllers where an MPU can enforce the intended partitions.
OxidOS targets medium-size MCUs and identifies zone ECUs, hardware security engines and hypervisor-related uses across Arm and RISC-V. Ferrocene’s qualified Armv7E-M targets create a direct technical overlap for Cortex-M4/M7-class implementations. That overlap is useful, but the safety case must still confirm the exact MCU, board support, compiler release, linker and startup code, OxidOS configuration, application subset and qualification/certification evidence.
| Ferrocene | OxidOS kernel | Sandboxed applications | Vehicle item |
|---|---|---|---|
| Qualified compiler on the selected target; safety manual and tool evidence | Scheduling, MPU use, capabilities, drivers and system calls | Independent Rust/C payloads, credentials, resource permissions and update units | Hazard analysis, requirements, integration tests and production certification |
Figure 3. Each layer contributes evidence; qualification does not flow automatically upward.
RISC-V needs careful language. OxidOS says it is RISC-V ready. Ferrocene’s current public table lists RV64GC Linux as Supported, not Qualified, and lists no qualified bare-metal RISC-V target. A programme may request new target enablement and qualification, but until that work and its evidence are complete, “supported by Rust” or “supported by OxidOS” cannot be presented as “qualified in Ferrocene.”
OxidOS presents its architecture for safety-critical automotive ECUs and has publicly used certification-oriented positioning. The public product page reviewed for this article does not provide an issued ISO 26262 product certificate with scope, version and target. The responsible wording is therefore “designed to support certification” or “certifiable architecture,” followed by a request for the current certificate, safety manual, assessment status and assumptions of use.
In 2026, OxidOS announced that a late-seed round was led by 42dot and described 42dot as strategic investor, technology partner and customer; the announcement was repeated by participating investor Inspire Capital. This is strong evidence of strategic alignment with Hyundai Motor Group’s SDV organisation. It does not disclose the production architecture, prove that OxidOS is 42dot’s Vehicle OS, establish deployment scale, or reveal commercial exclusivity.
Best fit. Ferrocene plus OxidOS is strongest for a new controller where the system can adopt a Rust-first OS, explicit application isolation and a qualified Arm toolchain from the outset. It is less naturally positioned as a transparent overlay on a mature AUTOSAR estate, although OxidOS states that both Rust and C applications can be hosted.
A two-track deployment and assurance model
| Ferrocene | OxidOS kernel | Sandboxed applications | Vehicle item |
|---|---|---|---|
| Qualified compiler on the selected target; safety manual and tool evidence | Scheduling, MPU use, capabilities, drivers and system calls | Independent Rust/C payloads, credentials, resource permissions and update units | Hazard analysis, requirements, integration tests and production certification |
Table 3. The two routes solve different adoption problems.
Practical next step. Run two evidence-led pilots, not two feature demos. For the incremental route, compile a small Arm service with Ferrocene, integrate it through an explicit C/Rust boundary, and trace timing, ownership and error contracts into the test plan. For the greenfield route, deploy independently built applications on an OxidOS-supported Arm board, demonstrate enforced resource separation, and map every binary and library to the selected Ferrocene qualification scope. Use the same evidence index for both so the trade-offs are visible.
The valuable work lies between supplier documents: configuration baselines, target enablement, reproducible builds, crate policy, FFI reviews, evidence mapping, safety-manual compliance and team training. This lets tQCS support both migration patterns without overselling either platform, while Ferrous Systems’ maintained Ferrocene evidence remains the shared toolchain foundation.
Sources
1. Ferrocene User Manual, “Compilation targets overview.” https://public-docs.ferrocene.dev/main/user-manual/targets/index.html 2. Ferrocene GitHub repository, current qualification status and services.
https://github.com/ferrocene/ferrocene
3. Ferrous Systems, “Ferrocene 25.11.0 now available,” including certified core subset.
https://ferrous-systems.com/blog/ferrocene-25-11-0/ 4. Veecle, “Development Studio White Paper 1.0.” https://veecle.io/media/pages/whitepapers/6b8196ce43-1774951080/veecle-development-studio-white-paper-1.0.pdf
5. Infineon, “Expands Rust ecosystem for AURIX with HighTec,” 5 April 2024.
https://www.infineon.com/technology-news/2024/infatv202404-089
6. OxidOS Automotive, product and architecture overview.
7. Inspire Capital / OxidOS announcement of 42dot-led financing and relationship.https://www.linkedin.com/posts/inspirecapitalvc_for-decades-critical-systems-have-been-built-activity-7468623165515145216-00Ir
Verification note. Sources were checked on 9 September 2026. The public Ferrocene manual cited above is the current development branch and warns that it may be incomplete; programme decisions should use the matching customer release documentation and certificates. Vendor claims are attributed where independent or certificate-level evidence was not public.