Wie Geofencing-Zonen funktionieren

Dieser Artikel bietet eine ausführliche technische Erklärung der Funktionsweise von Zonen in Levy Fleets, einschließlich der Durchsetzungspipeline, Fahrtende-Validierung, Ereignisprotokollierung und Kundenbenachrichtigungen.

Architekturübersicht

Levy Fleets verwendet Zonen in zwei Hauptkontexten:

1. Live-Telemetrie-Durchsetzung

Wenn ein Fahrzeug während einer aktiven Fahrt GPS-Koordinaten (Breitengrad/Längengrad) sendet, führt das System folgende Schritte aus:

• Lädt alle Geschwindigkeitsbegrenzungs- und Sperrzonen für das Unterkonto des Fahrzeugs
• Bewertet, ob der Fahrzeugstandort innerhalb von Zonenpolygonen liegt
• Sendet IoT-Befehle, um die Geschwindigkeit anzupassen oder den Motor nach Bedarf zu deaktivieren
• Protokolliert Zoneneintritts-/-austrittsereignisse
• Sendet Kundenbenachrichtigungen

2. Fahrtende-Validierung

Wenn ein Kunde versucht, eine Fahrt zu beenden, führt das System folgende Schritte aus:

• Lädt alle Park-, Parkverbots- und Sperrzonen
• Bewertet, ob der Endstandort die Parkanforderungen erfüllt
• Blockiert oder erlaubt das Fahrtende basierend auf der Zonenzugehörigkeit

Zonendatenstruktur

Zonen werden mit den folgenden Schlüsseleigenschaften gespeichert:

GeoJSON-Format

Zonengrenzen werden als GeoJSON Feature-Objekte gespeichert:

{
  "type": "Feature",
  "properties": {},
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [-122.4194, 37.7749],
        [-122.4180, 37.7749],
        [-122.4180, 37.7735],
        [-122.4194, 37.7735],
        [-122.4194, 37.7749]
      ]
    ]
  }
}

Echtzeit-Durchsetzungsablauf

Die Durchsetzungspipeline wird bei jeder GPS-Telemetrie-Aktualisierung von Fahrzeugen während aktiver Fahrten ausgeführt.

Schritt 1: Auslösebedingungen

Die Durchsetzung wird ausgelöst, wenn:

• Eine GPS-Aktualisierung von einem Fahrzeug empfangen wird
• Das Fahrzeug eine aktive Fahrt hat (ride_status = 'in_progress')
• Das Fahrzeug eine gültige IoT-IMEI konfiguriert hat
• Gültige Koordinaten bereitgestellt werden (endliche Breiten- und Längengrade)

Schritt 2: Zonenladen

Das System fragt alle speed_limit und no_go Zonen für das Unterkonto des Fahrzeugs ab, die nicht gelöscht sind.

Schritt 3: Punkt-im-Polygon-Auswertung

Für jede Zone verwendet das System einen Strahlenverfolgungsalgorithmus, um zu bestimmen, ob der Fahrzeugstandort innerhalb des Polygons liegt:

1. Einen Strahl vom Punkt ins Unendliche werfen
2. Zählen, wie oft der Strahl Polygonkanten kreuzt
3. Ungerade Anzahl = innen, Gerade Anzahl = außen

Das System bewertet die aktuelle Position des Fahrzeugs gegen alle geladenen Zonen und kategorisiert sie:

• Geschwindigkeitszonen: Alle speed_limit-Zonen, die das Fahrzeug enthalten
• Sperrzonen: Alle no_go-Zonen, die das Fahrzeug enthalten

Schritt 4: Aktive Einschränkungen bestimmen

Für überlappende Geschwindigkeitszonen:

• Das System berechnet die effektive Geschwindigkeitsbegrenzung für jede Zone
• Wenn die Zone einen speed_limit_kph-Wert hat, wird dieser verwendet
• Andernfalls wird auf die Einstellung slow_speed_zone_limit_kph des Unterkontos zurückgegriffen
• Das niedrigste Limit unter allen überlappenden Zonen wird angewendet

Für Sperrzonen:

• Jede Sperrzone, die das Fahrzeug enthält, löst eine Motorabschaltung aus
• Es muss nur eine Sperrzone übereinstimmen, damit die Durchsetzung erfolgt

Schritt 5: IoT-Befehlsversand

Basierend auf der Auswertung werden IoT-Befehle an das Fahrzeug gesendet, um Geschwindigkeitsbegrenzungen durchzusetzen oder den Motor zu deaktivieren.

Schritt 6: Befehlsdeduplizierung

Um unnötigen IoT-Verkehr zu vermeiden, werden Befehle dedupliziert:

• Wenn das Fahrzeug bereits in derselben Zone mit derselben Geschwindigkeitsbegrenzung ist, wird kein Befehl gesendet
• Der aktuelle Zonenstatus des Fahrzeugs wird verfolgt:
  • current_speed_limit_zone_id
  • current_speed_limit_kph
  • current_no_go_zone_id
  • engine_disabled_by_zone

Schritt 7: Statusaktualisierungen

Nach erfolgreichem Befehlsversand wird der Fahrzeugdatensatz mit dem neuen Zonenstatus und dem Durchsetzungszeitstempel aktualisiert.

Fahrtende-Validierung

Wenn ein Kunde versucht, eine Fahrt zu beenden, validiert das System seinen Standort gegen Zonenregeln.

Validierungsablauf

1. Alle Zonen laden (nicht nach Typ gefiltert)
2. Standortdaten abrufen:
   • devicePoint: GPS-Koordinaten des Kundentelefons (aus dem Anfragekörper)
   • vehiclePoint: Letzte bekannte GPS-Koordinaten des Fahrzeugs (aus der vehicles-Tabelle)
3. Validierungsmodus bestimmen aus Unterkontoeinstellungen
4. Zonenzugehörigkeit auswerten für jeden relevanten Punkt
5. Ergebnis zurückgeben (erlauben oder mit Fehlercode blockieren)

Validierungsregeln

Für jeden zu validierenden Punkt:

• Prüfen, ob der Punkt in IRGENDEINER Parkzone ist (type = 'parking')
• Prüfen, ob der Punkt in IRGENDEINER Sperrzone ist (type = 'no_go')
• Prüfen, ob der Punkt in IRGENDEINER Parkverbotszone ist (type = 'no_parking')

Ergebnisformel:

valid = inParking && !inNoGo && !inNoParking

Zonenpriorität

Bei überlappenden Zonen gilt folgende Priorität:

1. Sperrzonen - Blockieren immer, unabhängig von anderen Zonen
2. Parkverbotszonen - Blockieren Parken auch innerhalb einer Parkzone
3. Parkzonen - Nur gültig, wenn nicht in einer Sperr- oder Parkverbotszone

Parkzonenvalidierungsmodi

Unterkontoeinstellungen steuern, wie die Parkvalidierung funktioniert. Konfigurieren Sie dies unter Einstellungen -> Sonstiges -> Parkzonenvalidierungsmodus.

Nur Fahrzeug (Standard)

• Nur der GPS-Standort des Fahrzeugs wird geprüft
• Der Telefonstandort des Kunden wird ignoriert
• Fallback auf Telefonstandort, wenn der Fahrzeugstandort nicht verfügbar ist

Anwendungsfall: Am zuverlässigsten für fahrzeugzentrierte Operationen, bei denen das Telefon-GPS in Innenräumen ungenau sein kann.

Beide

• Sowohl Fahrzeug ALS AUCH Kundentelefon müssen in einer gültigen Parkzone sein
• Wenn eines fehlt, wird die Anfrage mit location_data_missing abgelehnt
• Restriktivster Modus

Anwendungsfall: Hochsicherheitsumgebungen, in denen Sie sicherstellen möchten, dass der Kunde physisch beim Fahrzeug ist.

Hybrid

• Entweder Fahrzeug ODER Kundentelefon kann in einer gültigen Parkzone sein
• Freizügigster Modus
• Besteht, wenn ein verfügbarer Punkt die Anforderung erfüllt

Anwendungsfall: Bereiche mit schlechter GPS-Abdeckung oder wenn Flexibilität bevorzugt wird.

Zonenereignisprotokollierung

Jeder Zoneneintritt und -austritt während aktiver Fahrten wird für Prüfungs- und Analysezwecke protokolliert.

Erfasste Ereignisdaten

Ereignisse anzeigen

Zonenereignisse können eingesehen werden:

• Auf der Fahrtdetailseite (Dashboard -> Fahrten -> [Fahrt] -> Zonen-Tab)
• Über Datenbankabfragen für Analysen
• Über die Partner-API für externe Integrationen

Kundenbenachrichtigungen

Kunden erhalten Push-Benachrichtigungen beim Betreten oder Verlassen von Zonen mit Durchsetzung.

Geschwindigkeitszonenbenachrichtigungen

Beim Betreten:

Titel: "Langsamzone aktiviert"
Text: "Ihr Fahrzeug ist jetzt auf 10 km/h in der Innenstadt-Fußgängerzone begrenzt."

Beim Verlassen:

Titel: "Langsamzone verlassen"
Text: "Sie haben die Innenstadt-Fußgängerzone verlassen. Ihre Höchstgeschwindigkeit ist wiederhergestellt."

Sperrzonenbenachrichtigungen

Beim Betreten:

Titel: "Sperrzone betreten"
Text: "Fahrtsteuerung im Privatgrundstücksbereich pausiert. Bewegen Sie sich in einen genehmigten Bereich, um fortzufahren."

Beim Verlassen:

Titel: "Sperrzone verlassen"
Text: "Sie haben den Privatgrundstücksbereich verlassen. Fahrtsteuerung ist wiederhergestellt."

Benachrichtigungsdeduplizierung

Um Benachrichtigungsspam zu verhindern:

• Eine 60-Sekunden-Abklingzeit gilt pro Zonen-/Ereigniskombination
• Doppelte Benachrichtigungen innerhalb dieses Fensters werden unterdrückt
• Benachrichtigungen werden für Prüfungszwecke protokolliert

GPS-Genauigkeitsüberlegungen

Die GPS-Genauigkeit variiert je nach Umgebung und beeinflusst das Zonenverhalten.

Typische Genauigkeitsbereiche

Hystereseschutz

Um "Flackern" an Zonengrenzen aufgrund von GPS-Rauschen zu verhindern, implementiert das System eine Hysterese:

Sperrzonenaustritts-Hysterese:

• Das Fahrzeug muss GPS-Punkte außerhalb der Zone für mindestens 15 Sekunden streamen, bevor die Motorleistung wiederhergestellt wird
• Verhindert falsche Austritte durch eine einzelne GPS-Messung, die nach außen driftet
• Wird über den no_go_enforced_at-Zeitstempel auf dem Fahrzeug verfolgt

Designempfehlungen

1. Pufferzonen: 5-10 Meter Spielraum an kritischen Grenzen lassen
2. Polygon-Einfachheit: Einfachere Formen sind weniger von GPS-Jitter betroffen
3. Zonengröße: Sehr kleine Zonen (< 20m Radius) werden möglicherweise nicht zuverlässig durchgesetzt
4. Testen: Zonengrenzen mit echten Geräten vor Ort validieren

Caching und Leistung

Geschwindigkeitsbegrenzungs-Caching

Die Einstellung slow_speed_zone_limit_kph des Unterkontos wird 60 Sekunden gecacht:

• Reduziert Datenbankabfragen während der Hochfrequenz-Telemetrieverarbeitung
• Cache ist pro Unterkonto
• Änderungen an Einstellungen brauchen bis zu 60 Sekunden zur Verbreitung

Fahrzeugmodell-Geschwindigkeits-Caching

Die Höchstgeschwindigkeit des Fahrzeugmodells wird 5 Minuten gecacht:

• Wird beim Wiederherstellen der Geschwindigkeit nach Verlassen von Geschwindigkeitszonen verwendet
• Cache ist pro Fahrzeugmodell-ID

Zonenladen

Zonen werden bei jedem Durchsetzungsaufruf neu geladen (nicht gecacht):

• Stellt sicher, dass Zonenänderungen sofort wirksam werden
• Abfragen sind mit Indizes auf subaccount_id, type und deleted_at optimiert

Leistungstipps

1. Zonenanzahl begrenzen: Weniger Zonen = schnellere Auswertung
2. Einfache Polygone: Weniger Eckpunkte = schnellere Punkt-im-Polygon-Prüfungen
3. Überlappende Zonen vermeiden: Reduziert die Anzahl der benötigten Auswertungen

Szenario-Handbuch

Szenario 1: Fahrt mit Parkvalidierung beenden

Einrichtung:

• Validierungsmodus: both
• Eine Parkzone deckt die Straße ab
• Eine Parkverbotszone deckt eine Laderampe innerhalb der Parkzone ab

Aktion: Kunde versucht, die Fahrt an der Laderampe zu beenden

Ergebnis:

1. Gerätepunkt: in Parkzone, in Parkverbotszone
2. Fahrzeugpunkt: in Parkzone, in Parkverbotszone
3. Validierung: inParking=true, inNoParking=true
4. Ergebnis: valid = true && !true = false
5. API gibt Fehler not_in_parking_zone zurück
6. Kunde muss Fahrzeug umparken

Szenario 2: Geschwindigkeitszonenübergang

Einrichtung:

• Zone A: speed_limit = 12 km/h
• Zone B: speed_limit = 8 km/h
• Unterkonto slow_speed_zone_limit_kph = 10 km/h

Aktion: Fahrzeug bewegt sich von außerhalb der Zonen -> Zone A -> Zone A+B Überlappung -> Zone B -> außerhalb

Ergebnis:

1. Außerhalb -> Zone A: Geschwindigkeitsbefehl gesendet mit Limit = min(12, 10) = 10 km/h
2. Zone A -> A+B: Geschwindigkeitsbefehl gesendet mit Limit = min(8, 10) = 8 km/h
3. A+B -> Zone B: Keine Änderung (immer noch 8 km/h, dedupliziert)
4. Zone B -> Außerhalb: Geschwindigkeit wiederhergestellt auf Fahrzeugmodell-Maximum (z.B. 25 km/h)

Szenario 3: Überlappende Geschwindigkeits- und Sperrzonen

Einrichtung:

• Geschwindigkeitszone, die einen Park abdeckt (10 km/h)
• Sperrzone, die eine Baustelle innerhalb des Parks abdeckt

Aktion: Fahrzeug fährt in die Baustelle

Ergebnis:

1. Geschwindigkeitsbegrenzung angewendet: 10 km/h (aus Geschwindigkeitszone)
2. Motor deaktiviert (aus Sperrzone)
3. Beide Ereignisse protokolliert
4. Kunde erhält Sperrzonenbenachrichtigung
5. Fahrzeug muss die Sperrzone verlassen UND 15 Sekunden warten, bevor der Motor wiederhergestellt wird
6. Geschwindigkeitsbegrenzung bleibt bei 10 km/h, bis das Fahrzeug auch die Geschwindigkeitszone verlässt

Szenario 4: GPS-Drift an Zonengrenze

Einrichtung:

• Sperrzonengrenze
• Fahrzeug befindet sich physisch am Rand
• GPS-Messungen schwanken zwischen innen/außen

Aktion: GPS-Messungen wechseln: innen -> außen -> innen -> außen (schnell)

Ergebnis:

1. Erste "innen"-Messung: Motor deaktiviert, Timer startet
2. Erste "außen"-Messung: Hystereseprüfung - Timer nicht abgelaufen, Motor bleibt deaktiviert
3. Zweite "innen"-Messung: Immer noch in Zone, Motor bleibt deaktiviert
4. Zweite "außen"-Messung: Hystereseprüfung - wenn >15s außen, Motor wiederhergestellt

Die 15-Sekunden-Hysterese verhindert, dass der Motor aufgrund von GPS-Rauschen schnell ein- und ausschaltet.

Servicegebiet und Außerhalb-der-Zone-Warnungen

Servicegebiet-Zonen definieren die Betriebsgrenze Ihrer Flotte und lösen Warnungen aus, wenn Fahrzeuge diesen Bereich verlassen.

Außerhalb-der-Zone-Warnungen konfigurieren

Funktion aktivieren:

1. Gehen Sie zu Dashboard -> Einstellungen
2. Navigieren Sie zum Abschnitt Sonstiges
3. Aktivieren Sie Außerhalb-der-Zone-Warnung

E-Mail-Empfänger konfigurieren:

1. Gehen Sie zu Einstellungen -> Warnungen
2. Aktivieren Sie Außerhalb-der-Zone-Warnungen unter Betriebswarnungen
3. Stellen Sie die E-Mail für kritische Warnungen ein

Warnungsauslösebedingungen

Eine Außerhalb-der-Zone-Warnung wird gesendet, wenn:

1. Ein Fahrzeug eine aktive Fahrt hat
2. Der GPS-Standort des Fahrzeugs außerhalb aller service_area-Zonen für das Unterkonto ist
3. Die Einstellung out_of_zone_alert_enabled true ist
4. Die E-Mail-Benachrichtigung out_of_zone_alerts aktiviert ist

Warnungsinhalt

Die E-Mail enthält:

• Fahrzeugnummer
• Letzter bekannter Standort
• Zeitpunkt der Erkennung
• Link zur Anzeige der Fahrt im Dashboard

Pufferzonenkonfiguration

Die Pufferzonen-Einstellung fügt einen GPS-Genauigkeitsspielraum um Zonengrenzen hinzu.

Zweck

GPS-Signale können je nach Umgebung um 5-15 Meter variieren. Die Pufferzonen-Einstellung hilft, diese Varianz zu berücksichtigen, indem sie:

• Spielraum um Zonengrenzen hinzufügt
• Falsch-positive Ergebnisse an Zonenkanten reduziert
• Die Durchsetzungszuverlässigkeit verbessert

Konfiguration

Stellen Sie die Pufferzone unter Einstellungen -> Sonstiges ein:

• Standard: 10 Meter
• Empfohlener Bereich: 5-15 Meter

Zonenanzeige in der mobilen App

Zonen werden auf der Karte der Kunden-App mit spezifischen Farben und Verhaltensweisen angezeigt.

Zonensichtbarkeit

Verhalten der mobilen App

Zonenladen:

• Zonen werden vom mobilen API-Endpunkt abgerufen
• 5 Minuten gecacht, um API-Aufrufe zu reduzieren
• Aktualisiert, wenn die App in den Vordergrund kommt

Zonenrendering:

• Als farbige Polygon-Overlays auf der Karte angezeigt
• Strichfarbe (Rand) ist gesättigter als Füllung
• Strichbreite: 2 Pixel

Behandlung ungültiger Koordinaten:

• Die mobile App validiert Zonenkoordinaten vor dem Rendern
• Prüft auf gültige Arrays mit mindestens 3 Koordinaten
• Validiert, dass jeder Punkt eine Zahl und endlich ist
• Überspringt stillschweigend Zonen mit ungültiger Geometrie

Zonenanalysen und Berichterstattung

Levy Fleets bietet umfassende Analysen für Zoneninteraktionen.

Zonenstatistiken

Zonenstatistiken liefern aggregierte Daten:

Dashboard-Analysen

Zonenanalysen sind an mehreren Dashboard-Stellen sichtbar:

1. Fahrtdetailseite -> Zonen-Tab

   • Chronologische Liste der Zonenereignisse
   • Eintritts-/Austrittszeiten
   • Durchgeführte Durchsetzungsmaßnahmen
   • Dauer in jeder Zone

2. Zonenverwaltungsseite

   • Zonennutzungszahlen (bei Erweiterung)
   • Letzter Aktivitätszeitstempel

Zonendaten exportieren

Zonenereignisdaten können exportiert werden über:

• Direkte Datenbankabfragen für erweiterte Analysen
• Fahrten-CSV-Exporte (enthalten Zonenereignisse, wenn verfügbar)
• Partner-API für Integration mit externen BI-Tools

Was kommt als Nächstes?

• Zonen erstellen und verwalten - Wie Sie Zonen erstellen und konfigurieren
• Geschwindigkeitsbegrenzungszonen - Detaillierte Anleitung zur Geschwindigkeitsbegrenzungsdurchsetzung
• Dashboard-Übersicht - Vollständige Dashboard-Anleitung