All procedures
Risk levels
Each procedure carries a risk tag.
- Low risk: writes are reversible; routine resets counters or updates an ageing model. The car continues to operate normally after the routine and the values can be set again.
- High risk: writes actuate hardware or trigger a state change the operator cannot abort by releasing a button. DPF regeneration is the only high-risk procedure currently in the catalog.
Why the routine IDs are unverified
The project’s v0.8.0 audit found that none of the routine IDs in src-tauri/src/data/service_functions.rs are chassis-validated. The reasons are documented in the file’s header comment: BMW service-function identifiers are not published; the project’s research notes (research/bmw_diag_landscape.md) confirm this is a security-sensitive surface.
The audit moved every routine ID to verified: false and shipped a UI convention: every service function renders an [UNVERIFIED] tag and prepends a “routine ID not chassis-validated” line to the run-confirmation dialog. This is write-path discipline per the project’s CONTRIBUTING.md: an unverified write can change ECU state, so the UI has to be explicit about it.
The path to verified is docs/validation/service-functions.md: a real-car harness report — same shape as docs/validation/dtc-history.md and docs/validation/injector-validation.md — against a known-good chassis, with the routine ID, the response, and the post-state verified. Each entry flips to verified: true only when that report lands.
Write-path discipline
Service functions are a write path. They invoke a routine on the target ECU and the ECU changes state. The consequences range from a counter reset (low risk) to actuation of a coolant pump (medium risk) to a 30-minute exhaust-temperature command (high risk).
The project’s discipline:
- Battery maintainer connected before any service routine runs. The target ECU needs stable voltage; a routine interrupted by a voltage drop can leave the ECU in an undefined state.
- Read the relevant state first. Confirm the procedure is appropriate. The car’s own fault memory tells you whether a CBS counter is overdue, whether the steering-angle sensor is out of calibration, whether the Valvetronic adaptation has drifted.
- Honest verification labels. The UI renders
[UNVERIFIED]for every routine ID currently shipped. Do not trust the routine on a customer’s car until the audit flips that label. - Real-car validation reports. Cross-check against ISTA on a non-critical car first. File the report in
docs/validation/service-functions.md. The routine ID flips toverified: trueafter that.
Service-reset questions
What procedures does Beemuu support?
Six: CBS reset, battery registration, steering-angle calibration, DPF regeneration, Valvetronic adaptation, EGS transmission adaptation.
Why are the routine IDs unverified?
BMW service-function identifiers are not published. The project does not have chassis-validated routine IDs for any procedure. The audit moved every ID to verified: false; the UI renders that honestly.
Can I use Beemuu for service resets today?
Use Beemuu to read the relevant state and confirm the procedure. For the actual write, cross-check against ISTA on a non-critical car first. Treat every routine ID as a placeholder until real-car validation lands.