Why the routine IDs are unverified.

Why this post

Beemuu ships 6 service functions: CBS reset, battery registration, steering-angle calibration, DPF regeneration, Valvetronic adaptation, EGS adaptation. Each one targets a specific module (DME, KOMBI, BDC, etc.) with a specific routine ID. The routine ID is the “do this thing” instruction the module understands.

The routine IDs are not published by BMW. They’re not in any open-source documentation, not in any third-party tool’s public schema, not in any forum post. They’re known to BMW’s internal tooling team and to the few indie shops that have reverse-engineered them.

The v0.8.0 cycle audit moved every routine ID to verified: false. The simulator accepts any routine ID; real BMW modules expect specific IDs that are not published. The project does not have chassis-validated routine IDs for any procedure.

What the audit found

The audit looked at every service_function entry in src-tauri/src/data/service_functions.rs. The findings:

• All 6 service functions have a routine ID placeholder.
• None of the routine IDs are chassis-validated against a real BMW module.
• None of the routine IDs match any open-source documentation.
• The verified: false label is honest.

The UI renders this honestly. Every service function in Beemuu’s Service Functions tab shows the “routine ID unverified” label and a cross-reference link to /verify.html so users know to verify against ISTA on a non-critical car first.

How a routine ID flips from unverified to verified

Every routine ID flips from verified: false to verified: true the same way: a real-car validation report. The harness for this is documented in docs/validation/service-functions.md.

What a validation report looks like:

1. Identify the chassis.

   The report covers one chassis (e.g. F30 335i, E90 335i). The routine ID may differ across chassis; each chassis needs its own report.

2. Run the procedure.

   Connect with Beemuu, run the service function routine on a real car, document the result. Was the routine accepted? Did the counter reset? Did the module respond?

3. Capture the wire trace.

   A cargo run --release -- --capture-trace run captures the UDS request and response bytes. The report includes the trace.

4. File a PR.

   The PR updates the service_functions.rs entry to verified: true with the chassis and the trace attached. A maintainer reviews and merges.

Once a routine ID has one verified chassis, the rest of the verification work is faster — you can cross-reference the wire trace against a similar chassis to confirm.

What this means for you

If you’re using Beemuu today, the service-function procedures are usable but not validated. The simulator accepts any routine ID; real cars may not. Always cross-reference against ISTA on a non-critical car first. The procedure runs or doesn’t based on the actual BMW module’s response.

If you have a real car and you’re willing to file a validation report, the project would benefit from your contribution. Every verified routine ID is a step toward production-ready service functions.

If you’re just curious about Beemuu’s design: this is the honest disclosure. The project doesn’t overstate what it knows. Every routine ID that flips to verified: true is a real win; until then, the audit label is the truth.