Boundary 01
Vehicle ingress
CAN and vehicle-Ethernet adapters normalize incoming data into canonical signal proposals without owning committed state.
Work in progress Selected work · Public platform architecture
Building a QNX-hosted vehicle property gateway
A QNX Hypervisor platform that keeps vehicle state authoritative in QNX Neutrino while delivering live, VHAL-compatible properties to native applications inside a Linux qvm guest.
- QNX Neutrino
- QNX Hypervisor / qvm
- Protobuf / gRPC
- Linux guest
- Unix-domain socket IPC
Vehicle-facing software and application workloads have different authority and lifecycle requirements. This public project keeps that boundary explicit: QNX Neutrino owns vehicle ingress, validates commands, commits state, and controls the Linux qvm lifecycle; the Linux guest consumes versioned state and presents it to cockpit applications.
A dedicated gateway carries snapshots, ordered updates, commands, health, and compatibility metadata across virtual Ethernet. The result is one traceable property flow across two operating systems without moving vehicle-state ownership into the guest.
What the platform demonstrates
The architecture separates vehicle-state ownership from application-facing property presentation. QNX remains responsible for ingress and committed state, while the Linux guest receives a stable interface tailored to native cockpit software.
- QNX-hosted authoritative vehicle state
- Source-neutral ingress for CAN and vehicle Ethernet
- Versioned snapshots and ordered live updates
- QNX-validated command and commit flow
- Guest-side VHAL property mapping and local IPC
- Explicit health, freshness, and disconnection states
- Gap detection and full snapshot resynchronization
- Cross-OS correlation, session, sequence, and time metadata
Architecture: ingress, QNX authority, and Linux guest
The platform is organized around three clear responsibility zones. Transport-specific input is normalized before reaching the authoritative QNX state store; only committed canonical state crosses into the application domain.
Boundary 02
QNX Neutrino host
/dev/vcar owns vehicle state. qnx_vehicle_service publishes snapshots and updates, accepts commands, and reports health.
Boundary 03
Linux qvm guest
linux_vhal_stub maps canonical signals into vehicle properties and serves a native cockpit client through local IPC.
Vehicle interfaces → QNX /dev/vcar → versioned Protobuf/gRPC over qvm virtual Ethernet → Linux VHAL-compatible service → Unix-domain socket → cockpit application
Keeping committed state in QNX
The Linux property cache is intentionally non-authoritative. Guest applications read and subscribe without a synchronous cross-OS round trip, but every value still originates from state committed in QNX.
This rule applies in both directions: incoming vehicle data and application commands become visible in Linux only after the QNX authority accepts and publishes them.
Read and subscription flow
Ingress adapters propose canonical signals to /dev/vcar. After QNX validates and commits a change, the gateway publishes it to the guest. The VHAL-compatible service maps the signal, updates its cache, and emits the corresponding property event to local subscribers.
Authoritative write flow
A cockpit HVAC request travels back through the same ownership boundary. Linux forwards the command but never commits it locally; the displayed property changes only after QNX accepts and republishes the committed state.
Stable contracts across the virtualized boundary
A versioned Protobuf/gRPC contract carries state snapshots, live updates, write requests, health, and compatibility negotiation over qvm virtual Ethernet. Canonical signal semantics stay independent of OS-specific APIs, allowing QNX and Linux components to evolve behind a deliberate compatibility boundary.
Host responsibilities
QNX owns the vehicle interfaces, authoritative resource manager, gateway service, startup ordering, recovery policy, and Linux guest lifecycle. Runtime responsibilities remain separated so services can be supervised and restarted independently.
Stable guest interface
Linux applications communicate only with the guest-side property service over a Unix-domain socket. The interface preserves selected AOSP-style vehicle-property semantics in a portable native-Linux service rather than an Android Binder HAL.
Recovery and end-to-end traceability
Health and freshness are part of the property contract, so a consumer can distinguish healthy, stale, and disconnected data. Stream gaps or guest restarts trigger a full authoritative snapshot before incremental updates resume, while QNX continues to own and ingest vehicle state.
Correlation IDs, source sequences, session IDs, and timestamps connect an ingress event or cockpit request to its QNX commit and Linux publication. That context turns failures at an OS boundary into an observable chain rather than a collection of unrelated logs.
Why this project is relevant to my work
The gateway brings together the engineering boundaries I work with professionally: QNX platform services, Linux guests, native IPC, virtualized networking, vehicle-data ownership, compatibility contracts, and restart-aware middleware. It is a public, inspectable demonstration of multi-OS platform design, separate from client or employer source code.