A modern passenger or commercial vehicle produces thousands of diagnostic events every journey. Powertrain, chassis, body and ADAS controllers exchange messages across CAN and CAN-FD, legacy comfort functions sit on LIN, and the emissions related subset is exposed through the OBD-II port.
Fault memory, freeze frame data, readiness monitors and live sensor values are all present. Almost none of that reaches the person driving. The driver gets a lamp on the cluster and, at best, a three word message. The interpretation happens later, at a workshop, using a diagnostic tool and a technician who was not there when the fault occurred.
The connected assistants deployed today push the question and often the vehicle context to a
backend. That introduces four problems at once.
| Where the cost sits | What actually happens |
|---|---|
| Driver | Uncertainty about whether the vehicle is safe to keep driving, leading to either unnecessary alarm or ignored warnings. |
| Dealer network | Diagnostic time consumed on faults that were self explanatory, and no-fault-found visits that carry full labour cost. |
| Roadside assistance | Callouts for conditions that did not require a callout. |
| Warranty | Late intervention on faults that degrade into more expensive failures. |
| Fleet operator | Vehicles taken off route on precaution rather than on evidence. |
| OEM brand | The warning lamp remains the least understood interface in the car. |
Two things changed. Small language models in the three to four billion parameter range became genuinely capable at instruction following and summarisation, and quantization matured to the point where those models fit the memory budget of an automotive grade system on module. The reasoning layer can finally sit next to the bus it is reasoning about.
The assistant is a single edge node on the vehicle network. It listens, reads live vehicle state, retrieves the relevant manufacturer documentation from local storage, reasons over all three, and speaks the answer back. Every stage runs on the AMD Kria KR260
| Principle | How it is enforced |
|---|---|
| Read only on the bus | The CAN transceiver is configured listen only. The assistant physically cannot transmit a frame onto the vehicle network. |
| Grounded answers only | The model answers from retrieved document text and decoded signals. If neither supports an answer it says so rather than generating one. |
| No egress | There is no outbound data path in the reference design. Audio, faults and location never leave the node. |
| Deterministic core untouched | All safety relevant behaviour stays in existing ECU software. The assistant is an explanation layer, not a control function. |
| Bounded memory | Every component has a fixed memory allocation. There is no dynamic growth path that can exhaust the module under load. |
| Signed everything | Model weights, retrieval index and application image are all signature verified before they are allowed to load. |
The AMD Kria KR260 robotics starter kit carries the K26 system on module. The KR260 is chosen over the KV260 because the carrier already exposes the Ethernet, PMOD and general interfaces that vehicle and industrial integration needs, rather than a vision oriented interface set.
| Element | Configuration |
|---|---|
| System on module | Kria K26, Zynq UltraScale+ MPSoC |
| Application processors | Quad core Arm Cortex-A53 |
| Real time processors | Dual core Arm Cortex-R5F |
| Programmable logic | On-module FPGA fabric with BRAM and URAM |
| On-module memory | 4 GB DDR4 with ECC support |
| Local storage | NVMe or eMMC, sized for model plus retrieval corpus |
| Boot | Secure boot chain with on-module non volatile storage |
The node is designed to run from switched vehicle 12 V through an automotive grade DC-DC stage with load dump and reverse polarity protection. Thermal design is the constraint that usually decides real world throughput, so it is treated as a first class requirement rather than a packaging afterthought.
| Interface | Purpose in this architecture |
|---|---|
| CAN 2.0B and CAN-FD | Live signal observation across powertrain, chassis and body networks at production bus rates. |
| ISO 15765-2 | Transport layer for segmented diagnostic messages. |
| UDS, ISO 14229 | Fault memory read, freeze frame retrieval and data identifier reads where the OEM permits them. |
| OBD-II | Emissions related fault codes, live data, readiness monitors and the standardised subset available on every vehicle. |
| LIN | Comfort and body subsystems where the fault is relevant to the driver. |
| DBC or ARXML | Signal database that turns raw frames into named, scaled, unit-bearing values. |
Raw CAN traffic is useless to a language model. The decode stage converts it into a compact, typed vehicle state object that the reasoning layer can be given directly, with names and units the documentation also uses.
Cabin audio is a harder problem than the model. Road noise, HVAC, wind, music and passengers all sit in the same band as speech, and the microphone is rarely where you would want it.
The generated answer is spoken back through Piper TTS or Coqui TTS, streamed as it is produced rather than synthesised after the full answer is complete. Streaming matters more than raw token rate for how fast the system feels, because the driver hears the first words while the rest is still generating.
| Stage | Design target |
|---|---|
| Wake to transcript | Complete before the driver finishes the sentence. |
| Vehicle state assembly | Read from the rolling buffer, no bus query needed. |
| Retrieval | Local index lookup, no network. |
| First spoken syllable | Sub second from end of utterance. |
| Full answer | Streamed continuously, no audible gap. |
A three billion parameter model at sixteen bit precision needs roughly six gigabytes for weights alone. The module has four. At four bit the same model comes down to approximately 1.7 gigabytes, which leaves working room for the key value cache, the speech models, the retrieval index and the operating
system.
The second effect matters more. Generating each token requires streaming the entire weight set out of DDR, so throughput is bound by memory bandwidth rather than by arithmetic. Halving the bytes per weight roughly doubles the achievable token rate.
| Planner responsibility | What it checks |
|---|---|
| Dependency ordering | Precedence expressed in the instruction is turned into an acyclic task graph and validated. |
| Feasibility | Is there a robot of the right type, free within the window, able to reach both locations. |
| Battery and duty | Does the assigned robot have enough charge for the full task chain plus a return margin. |
| Zone and access rules | Are all traversals and all destinations permitted for this robot type at this time. |
| Capacity | Does the destination have space, and is the load within payload limits. |
| Conflict | Does this plan contend with an already dispatched plan for the same robot, load or location. |
| Choice | Rationale |
|---|---|
| Group-wise 4-bit | Per-group scales preserve accuracy far better than a single tensor-wide scale, at negligible memory cost. |
| GPTQ or AWQ | Calibration on representative automotive text keeps the quality loss concentrated away from the domain that matters. |
| Sensitive layers kept wider | Embeddings and the output head carry disproportionate error, so they are held at higher precision. |
| Domain evaluation set | Accuracy is measured on decoded fault scenarios and manual questions, not on generic benchmarks. |
Context length is a memory decision, not a convenience. The key value cache grows linearly with context and competes directly with the weights for bandwidth. The design uses a short working context, aggressive retrieval rather than long prompts, and a fixed cap that cannot be exceeded at runtime.
This is where the engineering effort actually goes. Theoretical bandwidth on the module is a ceiling nobody reaches, and the gap between theoretical and achieved bandwidth is the single largest determinant of how the system performs in a vehicle
Every generated token requires the full weight set to cross the memory bus once. The upper bound on token rate is therefore achievable bandwidth divided by model bytes, and no amount of compute
optimisation moves it. Everything below is aimed at raising the achievable fraction.
| Symptom | Usual root cause |
|---|---|
| Token rate far below estimate | Dequantization on the processor side, so sixteen bit values are crossing the bus. |
| Throughput collapses with context | Key value cache traffic contending with weight streaming for the same bandwidth. |
| High variance between runs | Unaligned access patterns causing DDR row thrash. |
| Accelerator utilisation low | No double buffering, so compute idles during every transfer. |
| Good bench, poor vehicle | Thermal throttling not characterised, so sustained performance was never measured. |
The assistant answers from the manufacturer’s own material, held on local storage and versioned against the vehicle build. Nothing is answered from model parameters alone.
The reasoning layer operates under a strict contract. It may use the decoded vehicle state and the retrieved document text. It may not use anything else.
| Situation | Required behaviour |
|---|---|
| Retrieval returns strong match | Answer, and internally record which section was used. |
| Retrieval is weak or empty | State that the vehicle documentation does not cover the question and recommend contacting service. |
| Question outside scope | Decline and redirect, rather than improvising. |
| Fault is safety relevant | Give the manufacturer's stated instruction verbatim in substance, and do not soften it. |
| Conflicting sources | Prefer the newest technical service bulletin and say that guidance was updated. |
Answer quality is measured against a fixed regression set of decoded fault scenarios with known correct guidance, refreshed whenever the corpus or the model changes. Retrieval accuracy and answer faithfulness are scored separately, because they fail for different reasons and need different fixes.
The assistant is deliberately kept outside the safety path. It observes and explains. It does not actuate, it does not command, and it does not suppress or modify any existing warning
| Aspect | Position |
|---|---|
| Bus access | Listen only at the transceiver, enforced in hardware. |
| Existing warnings | Unchanged. The cluster behaves exactly as it does today. |
| Classification | Treated as a quality managed item, outside the ASIL decomposition, subject to confirmation with the OEM safety team. |
| Failure mode | Silence. If the assistant fails, the driver is exactly where they would have been without it. |
| Driver distraction | Voice first interaction, assessed against the applicable distraction guidelines for the target market. |
Even with no outbound path, the node is an attached device on a vehicle network and is treated as part of the attack surface.
Model, retrieval corpus and application are released together as one signed bundle with a single version number. Mixing versions is the most common way an on-device assistant starts giving wrong answers, so the design removes the possibility.
Quality has to be monitored without shipping conversations off the vehicle. The design uses aggregate, non-identifying counters read at service, such as refusal rate, retrieval miss rate and interaction counts by fault family. These indicate where the corpus is thin without exposing what any driver said.
| Phase | Scope | Exit criteria |
|---|---|---|
|
Phase 0 Assessment |
Vehicle architecture review, bus access and DBC availability, corpus audit, target variant selection. | Agreed reference configuration and integration decision. |
|
Phase 1 Bench prototype |
Model quantized and characterised on KR260, decode stack against recorded bus traces, retrieval built on real manuals. | Measured token rate, memory footprint and thermal envelope on the bench. |
|
Phase 2 In-vehicle pilot |
Installed in target vehicles, cabin acoustics tuned, duty cycle and thermal behaviour validated in use. | Sustained performance and answer quality against the regression set in the vehicle. |
|
Phase 3 Productionisation |
Security case, update path, homologation support, manufacturing and service documentation. | Release candidate bundle and signed off security assessment. |
|
Phase 4 Fleet rollout |
Staged deployment with rollback, corpus expansion by variant and market. | Agreed field quality thresholds held over the rollout window. |
These are the measures worth instrumenting from the pilot onward, because they are the ones a sponsor will be asked about.
| Measure | What it tells you |
|---|---|
| Containment rate | Share of driver questions answered without a service contact. |
| Time to explanation | Interval between fault detection and the driver understanding it. |
| Refusal rate | How often the corpus does not cover the question, which is the main signal for where to expand it. |
| Retrieval miss rate | Whether the index or the corpus is the weak link. |
| No-fault-found visits | Direct dealer cost avoided. |
| Roadside callout rate | Direct assistance cost avoided. |
| Sustained token rate | Whether the thermal design is holding in the field. |
| Risk | Mitigation |
|---|---|
| Thermal ceiling in cabin ambient | Characterise sustained rather than peak performance early, and design the enclosure for conducted cooling before software optimisation begins. |
| Corpus and build drift | Single signed bundle with one version number covering model, corpus and application. |
| Ungrounded generation | Strict retrieval contract, explicit refusal path, and a regression set that specifically tests refusal behaviour. |
| Bus access restrictions | Confirm DBC or ARXML availability and permitted UDS services with the OEM in Phase 0, before any design commitment. |
| Cabin acoustics | Microphone placement and beamforming tuned per vehicle model, not carried over from a reference cabin. |
| Multi language markets | Speech recognition, generation and corpus all have to move together, and each language multiplies validation effort. |
| Long lived signatures | Plan the migration to post quantum signing of artefacts against the service life of the vehicle. |