Pflegende Mobilität: Wenn autonome Autos Schlaglöcher selbst reparieren

Die Idee einer „pflegenden Mobilität“ ist weniger Sci‑Fi, als sie auf den ersten Blick wirkt – aber sie würde die Rollen von Fahrzeug, Betreiber und Kommune fundamental verschieben. Ich sehe das als nächsten Schritt nach „Connected Vehicles“ und „Software-Defined Vehicles“: Erst messen und verstehen, dann vorausschauend planen, dann physisch eingreifen.

Wie so ein System praktisch aussehen könnte

Statt dass jedes Fahrzeug Baustoffe mitführt, halte ich ein mehrstufiges Flottenmodell für realistischer:

1. Erkennen & kartieren (Crowdsensing)

   • Serienfahrzeuge (oder Robotaxis) detektieren Straßenschäden über Kameras, Radar/LiDAR, Mikrofon/Vibration (Fahrwerk) und IMU.
   • Edge-Auswertung im Fahrzeug, um Bandbreite zu sparen und Datenschutz zu wahren.
   • Ergebnis: standardisierte „Road Health“-Events mit Position, Tiefe/Größe, Dringlichkeit.

2. Validieren & priorisieren (Digitaler Zwilling der Straße)

   • Kommunen oder Betreiber führen einen digitalen Zwilling, der Schäden über Zeit bewertet (Wachstum, Unfallrisiko, Wasserzutritt/Frost).
   • Daraus entsteht eine priorisierte „Repair Queue“.

3. Reparieren (Spezialfahrzeuge statt Alleskönner)

   • Einige wenige Wartungsfahrzeuge (autonom oder teilautonom) führen Material und Werkzeuge mit.
   • Reparaturformen:
     • Mikro-Reparaturen: Risse versiegeln, kleine Ausbrüche füllen (Kaltasphalt/Harz/Füllstoffe).
     • Additive Reparatur: eher für definierte Bauteile (Randsteine, Abdeckungen, temporäre Leitelemente) als für klassisches Asphalt-„3D-Drucken“.

Gerade bei Asphalt ist „integrierter 3D-Druck“ im Auto schwierig: Materialhandling, Temperaturführung, Verdichtung und Haftung sind die eigentlichen Killerkriterien.

Technische Hürden (die man wirklich lösen muss)

1) Detektion mit zuverlässiger Klassifikation

• Ein Schlagloch ist nicht nur ein „Loch“, sondern hat Geometrie, Feuchte, Unterbauzustand.
• Für Haftung und Haltbarkeit muss man unterscheiden: oberflächlicher Ausbruch vs. struktureller Schaden.
• Dafür braucht es robuste Sensorfusion plus Trainingsdaten über Jahreszeiten.

Ein guter Einstieg ist alles, was unter vernetzten Fahrzeugdaten und Cyber-Security fällt, weil man sich sonst mit manipulierten Meldungen das System kaputtmacht: warum Konnektivität ohne Cybersicherheit bei solchen Flotten-Use-Cases nicht funktioniert und auch konkrete Risiken im vernetzten Fahrzeug und wie man sie absichert.

2) „Repairability“ der Oberfläche: Material + Prozess

• Bei echten Schlaglöchern reicht „reinspritzen“ selten.
• Notwendig wären Mini-Prozesse: Reinigen, Trocknen, ggf. Kanten anfräsen, Haftvermittler, Füllen, Verdichten, Aushärten.
• Das ist mechanisch aufwändig und braucht Zeitfenster (Verkehr!).

Realistischer ist zunächst:

• Rissversiegelung (verhindert Wassereintritt und Frostsprengung).
• Temporäre Reparatur bis zur planmäßigen Instandsetzung.

3) Edge-Computing und Latenz

Für die operative Ausführung (z.B. „ich repariere jetzt“) brauchst du:

• extrem präzise Lokalisierung (Lane-Level),
• Live-Verkehrslage,
• sehr schnelle Entscheidungslogik.

Das spricht für verteilte Intelligenz: Fahrzeug + Edge-Knoten entlang der Strecke. Dazu passt gut: wie Edge Computing und 5G vernetzte Mobilität beschleunigen können.

4) Safety: Reparieren im fließenden Verkehr

• Ein Fahrzeug, das anhält oder langsam fährt, ist ein Risiko.
• Man bräuchte V2X-Warnungen („Mobile Baustelle“) und dynamische Absicherung.

Hier ist V2X nicht nice-to-have, sondern Grundlage: V2X-Kommunikation für intelligente Verkehrssysteme und sichere Koordination.

5) Betrieb & Wartung der Reparatureinheit

Ironisch, aber wichtig: Das Reparatursystem selbst braucht Predictive Maintenance (Verstopfung, Aushärtechemie, Pumpen, Düsen). Sonst werden aus „heilenden Autos“ schnell „liegengebliebene Baustellen“. Dazu passt: wie Predictive Maintenance Ausfälle in Fahrzeugen und Produktion reduziert.

Wer haftet, wenn das Auto zum Bauarbeiter wird?

Ich glaube, die rechtliche Verantwortung würde sich nicht komplett vom Staat weg verschieben – aber sie würde granularer.

Ein mögliches Modell:

• Kommune/Staat bleibt verantwortlich für Straßensicherheit im Ganzen und erteilt Betriebsgenehmigungen/Standards.
• Flottenbetreiber (z.B. Robotaxi-Anbieter) haftet für ordnungsgemäße Ausführung im Einsatz (wie heute ein Bauunternehmer).
• Hersteller/Zulieferer haftet produktrechtlich für Systemfehler (Defekt, falsche Materialdosierung durch Softwarebug).

Damit das funktioniert, braucht es:

• zertifizierte Reparaturklassen (temporär vs. dauerhaft),
• Auditierbare Logs (wann, wo, womit, unter welchen Bedingungen repariert),
• klare Abnahme- und Monitoringprozesse.

Blockchain wird hier oft reflexartig genannt; ich sehe es pragmatisch: Nicht als Hype, sondern als Option für manipulationssichere Nachweise in Multi-Party-Ökosystemen. Wer tiefer einsteigen will: wie Blockchain Lieferketten, Mobilität und Datensicherheit verbinden kann.

Könnte das wirklich Kosten senken?

Ja – aber nicht primär durch „alles wird automatisch repariert“, sondern durch:

• Früherkennung (kleine Schäden günstig entschärfen, bevor sie groß werden),
• bessere Priorisierung (Budget dahin, wo Risiko/Schaden am höchsten ist),
• weniger Streufahrten von Bauhöfen (dank datengetriebener Einsatzplanung),
• weniger Folgeschäden an Fahrzeugen und weniger Unfälle.

Die größte Ersparnis sehe ich in der Kombination aus Daten + Planung + gezielten Mikrointerventionen.

Meine Vision (und eine provokante Frage zurück)

In 5–10 Jahren halte ich das für realistisch:

• Serienfahrzeuge melden Schäden hochzuverlässig.
• Kommunen betreiben digitale Straßenzwillinge.
• Autonome Wartungsfahrzeuge führen nachts Mikro-Reparaturen und Markierungen aus.

Die provokante Frage: Wollen wir wirklich, dass OEMs (oder Robotaxi-Plattformen) zu „Infrastrukturbetreibern“ werden – oder sollten wir das als öffentlich regulierte Dienstleistung mit offenen Standards bauen, damit die Datenhoheit nicht bei wenigen Playern landet?

Wenn ihr wollt, kann ich auch ein mögliches Standard-Set skizzieren (Datenformat, Reparaturklassen, Sicherheitsanforderungen), das Kommunen in Ausschreibungen nutzen könnten.