Rae
Vehicle software & systems architecture
Los Angeles, CA
I decide how vehicle systems are partitioned, how the parts talk, and how every requirement stays traceable to the design, code and evidence that satisfy it. Three powertrains below — hydrogen fuel-cell, battery-electric and hybrid — each with the architecture I chose, the ones I did not, and why.
01 — Projects
Three powertrains, three architectures
Big Red
Class 6 hydrogen fuel-cell truck on a Kenworth T280. Sole embedded software engineer, blank platform to integrated vehicle.
Open case study →- Architecture
- Partitioned by subsystem: supervisory controller over supplier subsystem ECUs; gateway-segmented CAN; multi-rate supervisor
- Traceability
- Pinout data as the single source of truth — architecture views generated, never hand-edited
- Contrasted with
- The same truck redrawn as a zonal architecture
- Evidence
- 7+ ECUs · bus load 85% → 60% · fault isolation 6 h → 10 min
Concept car
Autonomous driving function for a battery-electric concept car, taken through the software V-model on a microcontroller.
Open case study →- Architecture
- Layered embedded control: Stateflow sequencing, PID control law, vendor device layer below an I²C boundary
- Traceability
- Requirement IDs read from the spec by a CI gate; broken links fail the build
- Contrasted with
- Timed script · absolute waypoints · behaviour tree; encoder vs camera vs sensor fusion
- Evidence
- 17 requirements · 3 verification stages · failures reported as recorded
Prius openpilot
openpilot's engage state machine ported to C++, replayed against my own drives in a 2018 Prius from a comma 3X, and run in the browser.
Open case study →- Architecture
- Dependency-isolated library stack: log reader → pure state machine → differential replay → CLI, diagram and WebAssembly front-ends
- Traceability
- Logged behaviour traced back to the exact transition-table row that fired
- Contrasted with
- elif chain · Stateflow with generated code · formal statechart
- Evidence
- 1,989,710 ticks replayed · 89/89 transitions aligned
02 — Across projects
Two questions every architecture review asks
Should this be zonal?
An animated six-step tutorial, an honest weighing tool, and Big Red as built by subsystem next to a zonal redesign of the same chassis.
Zonal vs non-zonal →Can you prove it?
Four ways to keep requirements, design and evidence linked — generated views, model links, CI gates, replay — and where each broke.
Traceability →03 — How I document an architecture
Habits that show up in all three
Decisions as records
Context, decision, rejected options, consequences — written so the next engineer can disagree with the reasoning, not guess at it.
Data first, drawings second
Interfaces live in a schema or a table. Diagrams are generated from it, so the picture cannot drift from the system.
Evidence labelled honestly
Measured, simulated, schematic and analysed are different claims. Each figure says which one it is, including the runs that failed.
Trained in C4, arc42 and Kruchten 4+1 view documentation and DOORS-to-Enterprise-Architect traceability through M.Eng coursework; the case studies apply those views to work done on real hardware.
04 — Also
Tooling around the engineering
agent-skills public repo
Claude Code skills I wrote: document and scan pipelines, machine inventories, session cost telemetry, and a delegating orchestrator with human approval gates.
Everything else
Design and fabrication, systems and storage, and CAN tooling stay on the previous site.