Process 01
qnx_provider_sim
A temporary authority simulator that owns canonical values, publishes changing speed data, validates HVAC requests, and emits committed changes.
Selected work · Public technical demonstration
Building a Linux-native, Android VHAL-compatible property service
A C++17 and Protobuf/gRPC demonstration of vehicle-property flow across an authoritative provider, a guest-side cache, and native Linux applications.
- C++17
- Protobuf / gRPC
- Ubuntu 24.04
- Unix-domain socket IPC
- Automotive property mapping
Vehicle data in a multi-OS automotive platform often has to cross a clear authority boundary before applications can consume it. I built this public, standalone project to demonstrate that flow without proprietary vehicle code or a full Android Automotive OS environment.
The result is a Linux-native service shaped around selected Android Vehicle HAL concepts. It maps canonical vehicle signals to Android-compatible properties, keeps a non-authoritative guest cache, serves native Linux clients through a Unix-domain socket, and sends writes back to the authority for validation and commitment.
What the project demonstrates
The project separates the system into an authoritative vehicle provider and a consumer-side property service. Applications can discover property metadata, issue batched reads and writes, subscribe to events, and check provider health without communicating with the provider directly.
- Initial state synchronization from a provider snapshot
- Canonical-signal-to-vehicle-property mapping
- Batched
GetValuesandSetValuesoperations - Continuous and on-change server-streamed subscriptions
- Access, area, type, and range validation
- Provider health reporting and reconnection
- Native Linux IPC over a Unix-domain socket
Architecture: authority, mapping service, and client
The current development topology contains three native Linux executables, all running on Ubuntu 24.04.
Process 02
linux_vhal_stub
The guest-side service that synchronizes state, maps signals, maintains a non-authoritative cache, validates requests, and serves local clients.
Process 03
vehicle_client
A console client used to list configurations, read and write properties, subscribe to events, and inspect provider health.
CanonicalVehicleProvider over gRPC/TCP → mapping service → LinuxVehicleHal over a gRPC Unix-domain socket
Property mapping and behavior
The service advertises four implemented properties rather than pretending to cover the complete Android Vehicle HAL surface.
| Property | Access | Change mode | Area | Behavior |
|---|---|---|---|---|
PERF_VEHICLE_SPEED | Read | Continuous | Global | Canonical km/h converted to m/s |
GEAR_SELECTION | Read | On change | Global | Canonical gear mapped to Android-compatible enum values |
IGNITION_STATE | Read | On change | Global | Canonical state mapped to Android-compatible enum values |
HVAC_TEMPERATURE_SET | Read/write | On change | Row-one-left seat | Validated range of 16–30 °C |
Known properties without an authoritative value return STATUS_TRY_AGAIN. Unknown or malformed requests return STATUS_INVALID_ARG. Writes to read-only properties return STATUS_ACCESS_DENIED.
Keeping the authority upstream
The guest cache is deliberately non-authoritative. On startup, the service requests a complete snapshot and then subscribes to canonical updates. Reads are served from the latest received cache instead of synchronously querying the provider.
For a writable HVAC target, the guest validates the request and forwards it upstream. It does not commit the value locally. The cache changes only after the authority accepts the command and publishes the committed value back through the update stream.
Provider loss and recovery
The service can start before the provider. Until the initial snapshot arrives, health is DISCONNECTED and reads return STATUS_TRY_AGAIN. If the provider stream ends, the service retries once per second and resynchronizes from a fresh snapshot when the provider returns.
Explicit current limitation
The demonstration retains cached values while disconnected. Explicit stale-value marking is documented as future work, keeping the current behavior visible instead of implying guarantees the project does not yet provide.
Automated end-to-end validation
The repository includes a smoke test that builds the three executables, starts the provider and service, waits for a healthy connection, verifies property metadata, reads vehicle speed, writes an HVAC target, confirms the committed value, and checks that a speed subscription receives events.
This is intentionally a focused integration test for the demonstrated property flow; it is not a claim of production qualification or complete VHAL conformance.
Current scope and intended QNX integration
Today, every executable runs natively on Ubuntu 24.04. The authority is a simulator; there is no QNX binary in this repository.
The intended deployment replaces only the simulator with a QNX-hosted vehicle service. The Linux VHAL-compatible service and its application-facing Unix-socket interface are designed to remain unchanged inside an Ubuntu qvm guest, with Protobuf/gRPC crossing the virtual Ethernet boundary.
Why this project is relevant to my work
The project makes a public, inspectable version of the engineering patterns I work with professionally: C++ middleware, QNX/Linux and Android-facing boundaries, Protobuf/gRPC services, vehicle-data mapping, explicit ownership, and multi-OS integration. It is a standalone demonstration, not client or employer source code.