Vehicle Software Infrastructure

The CI/CD workflows had to produce the correct artifacts for multiple hardware architectures and move them through development and target environments consistently. Repetition was moved into pipeline logic so developers did not have to remember a different manual sequence for every target.

The useful part of this work was not a single pipeline file. It was making build, tagging, deployment, service orchestration, and update behavior agree across the system. A failure at any one of those boundaries can leave an embedded target difficult to inspect or recover.

I taught myself Rust on the job and used it to implement a REST-based OTA update mechanism on three test vehicles. The updater checks versions, coordinates services, monitors health, and falls back when the new state is not healthy.

That work changed how I thought about deployment. On a remote or embedded target, an update is not complete when new files arrive. It is complete when the correct services start, the expected health signals appear, and the device still has a route back if they do not.

The environment required practical decisions around Linux services, containers, architecture-specific artifacts, and automated recovery. I had to learn unfamiliar parts of the stack quickly while still producing work that fit an existing engineering system.

The public description stays general because the hardware, deployment topology, and internal platform details are confidential. The transferable work is the delivery model: reproducible builds, target-aware packaging, observable service startup, and defensive updates.