Techniker-Routen
Techniker-Routen sind die dritte Fähigkeit von AI Ops. Der Solver nimmt zwei Stopp-Arten — Akku-Tausch und Rebalance-Bewegungen — und packt sie zu einer einzigen geordneten Route pro Techniker pro Schicht zusammen. Der Techniker arbeitet die Route in der operator-app ab.
Diese Funktion ist nur aktiviert, wenn ai_ops_tier='enterprise' für den Subaccount gesetzt ist.
Was in eine Route fließt
Der Routenbauer läuft alle 30 Minuten während der Betriebszeiten (06:00-22:00 Ortszeit). Für jeden Techniker im Dienst sammelt er:
- Fahrzeuge mit niedrigem Akku unter dem Tauschschwellenwert — daraus werden swap-Stopps.
- Akzeptierte Rebalance-Empfehlungen — jede wird zu einem pickup-Stopp und einem dropoff-Stopp, gepaart (dasselbe Fahrzeug muss erst eingeladen, dann abgesetzt werden).
- Start- und Endort des Technikers für die Schicht.
- Das Schichtfenster (Startzeit, Endzeit).
- Fahrzeugkapazität — wie viele Fahrzeuge gleichzeitig in den Transporter des Technikers passen.
Der Solver minimiert die gesamte Fahrzeit unter der Bedingung, dass alle Stopps ins Schichtfenster passen, alle pickup → dropoff-Paare in Reihenfolge eingehalten werden und die Kapazität nie die Transporter-Grenze überschreitet.
Stopp-Arten
| Art | Bedeutung |
|---|---|
| swap | Akku-Tausch vor Ort. Der Techniker tauscht den Akku, fährt weiter. Das Fahrzeug bleibt in derselben Hex-Zelle. |
| pickup | Der Techniker lädt ein überversorgtes Fahrzeug in den Transporter. |
| dropoff | Der Techniker setzt ein zuvor geladenes Fahrzeug am Rebalance-Ziel ab. |
Eine Route wechselt zwischen Pickups und Dropoffs, während sich der Transporter füllt und leert. Swap-Stopps können an beliebiger Stelle in der Sequenz vorkommen.
Solver
Levy AI Ops wird mit drei Solver-Implementierungen ausgeliefert und wählt zur Laufzeit:
- OR-Tools — Googles Open-Source-Routenplaner, als FastAPI-Microservice bereitgestellt. Respektiert pickup/delivery-Paare, Zeitfenster, Kapazität und nutzt die Metaheuristik GUIDED_LOCAL_SEARCH mit 5-Sekunden-Zeitlimit. Standard, wenn
ORTOOLS_SOLVER_ENDPOINTkonfiguriert ist. - Routific — kostenpflichtige API, höherwertige Lösungen für größere Routen. Wird verwendet, wenn
ROUTIFIC_API_TOKENgesetzt ist. Am besten für Routen mit 30+ Stopps. - Lokaler Savings-Solver — ein reiner TypeScript-Clarke-Wright-+-2-opt-Fallback, der in Node läuft. Reicht für Routen mit bis zu ~30 Stopps in unter 100 ms. Wird verwendet, wenn keiner der Remote-Solver konfiguriert ist.
Der aktive Solver wird in rebalance_routes.solver_version festgehalten, sodass Sie nachvollziehen können, welcher Lauf welche Engine nutzte.
Die Auto-Maintenance-Regel
Beim Bau einer Route wird jedes Fahrzeug, das an einem Pickup-Stopp hängt, automatisch auf Status maintenance gesetzt. So wird verhindert, dass ein Rider das Fahrzeug greift, bevor der Techniker eintrifft.
Das Fahrzeug bleibt in maintenance, bis eines davon eintritt:
- Der Techniker schließt den Pickup-Stopp ab (Fahrzeug bleibt während der Fahrt im Transporter in
maintenance, dann zurück aufavailablebeim Dropoff). - Die Route wird abgebrochen (Fahrzeug fällt sofort zurück auf
available). - Der Techniker schließt einen swap-Stopp ab (Fahrzeug zurück auf
available, sobald der Tausch protokolliert ist).
Das ist das einzige Element von AI Ops, das ohne Operator-Review eine Aktion auslöst. Es ist gewollt und auf das Pickup-Fenster einer aktiven Route beschränkt.
Routen-Tabelle
Eine Route wird in rebalance_routes mit diesen Schlüsselfeldern gespeichert:
| Feld | Bedeutung |
|---|---|
subaccount_id | RLS-Scope |
technician_id | Der zugewiesene Benutzer |
shift_start / shift_end | Das Fenster, das der Solver respektiert hat |
status | planned → in_progress → completed / abandoned |
solver_version | Welche Engine die Route gebaut hat |
total_distance_m | Distanzschätzung des Solvers |
estimated_minutes | Zeitschätzung des Solvers |
Jeder Stopp liegt in rebalance_route_stops:
| Feld | Bedeutung |
|---|---|
sequence | 0-indexierte Reihenfolge entlang der Route |
stop_type | pickup / dropoff / swap |
vehicle_uuid | Fahrzeug, auf das sich der Stopp bezieht |
destination_h3 | Für Dropoffs: die Zielzelle |
eta | Vom Solver geschätzte Ankunft |
time_window_end | Spätester akzeptabler Ankunftszeitpunkt |
completed_at | Wann der Techniker den Stopp als erledigt markiert hat |
completion_note | Optionale Freitext-Notiz |
Sonderfälle
| Situation | Was passiert |
|---|---|
| Techniker akzeptiert die Route nicht | Status bleibt planned. Auto-Maintenance wird nicht angewendet, bis der Techniker auf Accept tippt. |
| Techniker tippt auf Abandon | Auto-Maintenance-Fahrzeuge fallen zurück auf available. Unvollständige Empfehlungen werden wieder geöffnet. |
| Zu viele Stopps für das Schichtfenster | Solver liefert die längste machbare Teilmenge. Überschüssige Stopps bleiben als open-Empfehlungen für die nächste Route oder den nächsten Techniker. |
| Kein Techniker im Dienst | Routen werden nicht erzeugt. Empfehlungen laufen weiter im Operator-Dashboard auf. |
| Solver-Timeout (>5 s bei OR-Tools) | Das System fällt für diesen einen Lauf auf den lokalen Savings-Solver zurück. Sentry-Warnung wird emittiert. |
Den Gewinn messen
Die akademische Literatur zum kombinierten Swap-+-Rebalance-Routing nennt grob 50 % Reduktion der Fahrtdistanz gegenüber separaten Swap- und Rebalance-Routen. In der Praxis sind 30-50 % je nach Flottendichte und Schichtlänge realistisch. Das Feld total_distance_m auf jeder Route ist die Messung: Vergleichen Sie eine Woche AI-Ops-Routen mit einer Woche manuell geplanter Routen, um den Delta zu sehen.
Verwandt
- Operator-App-Routen — was der Techniker in der App sieht.
- Rebalance-Empfehlungen — die Eingabe für den Routenbauer.
- Feature-Flags und Stufen —
ai_ops_tier='enterprise'ist erforderlich.