English
Deutsch
Deutsch
  • SWARM Dokumentation
  • Was ist neu?
    • Version 2023.3
      • Update 1
  • Kurz und bündig
    • Übersicht: Swarm Perception Platform
  • Quick start guide
    • P101, P401 und OP101
      • P101 - Perception Box
      • P401 - Perception Box
      • OP101AC - Outdoor Perception Box
      • OP101DC - Outdoor Perception Box
    • Virtual Perception Box
      • Systemanforderungen
      • VPX Agent auf NVIDIA Jetson (Jetpack 4.6) installieren
      • VPX Agent auf NVIDIA Jetson Orin (Jetpack 5.1.x) installieren
      • VPX Agent auf X86/NVIDIA Server installieren
      • IotEdge von 1.1 auf 1.4 upgraden
  • Lösungsbereiche
    • Traffic Insights
      • Setup: Verkehrszählung
      • Setup: Verkehrszählung mit Geschwindigkeitsschätzung
      • Setup: Analysen von Kreuzungen
    • Parking Insights
      • Setup: Schrankenloses Parken
      • Setup: Schrankenloses Parken mit ANPR
        • ANPR: Anleitung und Hilfestellungen
      • Setup: Einzel- und Mehrplatzerfassung
        • Standardbeispiele
    • Advanced Traffic Insights
      • Setup: Adaptive Traffic Control
      • Setup: Journey Time & Traffic Flow
        • Installationsanleitung
        • Technisches Konzept
      • Setup: Verkehrsstaus
    • People Insights
  • Swarm Control Center
    • Geräte
      • Kamera- und Gerätemonitoring
      • Kamerakonfiguration
        • Szenariokonfiguration
          • Modelle
          • Kalibrierung
          • Kameraeinstellungen
        • Rule-Engine
          • Anwendungsbeispiele für die Rule-Engine
      • Device Health
    • Data Analytics
      • Erstellung und Organisation von Dashboards
      • Dashboard-Übersicht und Widgets
        • Verkehrsszenarien
        • Parkplatzszenarien
        • Generisches Szenario
    • Datenintegration
      • Data Analytics API (REST API)
      • Rohdaten via Custom-MQTT-Server
      • Swarm Control Center API
    • Administration
      • Monitoring Alerts
      • Lizenzmanagement
      • Benutzermanagement
  • Test & Performance
    • Benchmarks
      • Wie messen wir die Performance?
    • Whitepaper für Anwendungsfälle
      • Verkehrszählung
      • Schrankenloses Parken und ANRP
  • Useful knowledge
    • 🚒Tipps zur Fehlerbehebung
    • Netzwerkanforderungen
    • SCC: Browserkompatibilität
    • Unsere Objektklassen
    • Ortskennzahl für Nummernschilder
  • Guidelines
    • Wie kann ich auf den Debug-Mode zugreifen?
    • Wie kann ich Azure ioTHub als Custom-Broker verwenden?
  • Getting Support
    • Kontaktieren Sie uns
    • FAQs
Powered by GitBook
On this page

Was this helpful?

Export as PDF
  1. Lösungsbereiche
  2. Advanced Traffic Insights
  3. Setup: Journey Time & Traffic Flow

Technisches Konzept

In diesem Abschnitt erläutern wir, wie die Erkennung und der Abgleich der Journey Times aus technischer Sicht funktionieren.

PreviousInstallationsanleitungNextSetup: Verkehrsstaus

Last updated 1 year ago

Was this helpful?

Um Fahrten von Fahrzeugen zu erkennen, muss dasselbe Fahrzeug an mehreren vordefinierten Orten erkannt werden. Das bedeutet, dass es einen speziellen Identifikator geben muss, um zu erfassen, ob es sich wirklich um dasselbe Fahrzeug handelt und nicht verschiedene.

Bei Fahrzeugen ist der eindeutige Identifikator natürlich das Nummernschild. Daher wird dieses für den Abgleich von Fahrzeugen an verschiedenen Standorten verwendet. Da Nummernschilder als personenbezogene Daten gelten, wird eine angewendet, um die personenbezogenen Daten zu pseudo-anonymisieren.

Wie funktioniert das?

Auf Grundlage unseres Standardanwendungsfalls für die Verkehrszählung wird das Objekt (Fahrzeug) zunächst erkannt und klassifiziert. Wenn das Journey-Time-Feature aktiviert ist, führt der Algorithmus eine Kennzeichenerkennung sowie -lesung für jedes detektierte Fahrzeug durch. Der Raw String des Kennzeichens, also die unbearbeitete Zeichenabfolge, wird dann mit einem sogenannten Hashing-Mechanismus pseudonymisiert, und der pseudonymisierte Zufallstext wird im Rahmen eines Events, welches durch das Überfahren einer Counting Line getriggert wird, über das verschlüsselte Netzwerk gesendet.

Im folgenden Abschnitt werden die einzelnen Schritte näher beschrieben.

Fahrzeugerkennung

In jedem Videoframe werden Fahrzeuge erkannt und als Pkw, Lkw oder Bus klassifziert. Außerdem wird das Fahrzeug über die einzelnen Frames hinweg getrackt.

Kennzeichenerkennung

Für jedes klassifizierte Fahrzeug wird nun das Nummernschild erkannt und dem Objekt entsprechend zugeordnet.

Lesen des Kennzeichens

Nun wird für jedes erkannte Kennzeichen eine optische Zeichenerkennung (OCR) angewendet, um das Nummernschild zu lesen. Der Output ist ein Text, der die Raw Strings, also die Rohzeichenfolge, des Kennzeichens enthält.

Pseudonymisierung des Kennzeichens (Hashing)

Um die Nummernschilder erfolgreich zu pseudonymisieren, erzeugt ein sogenannter Salt Shaker zufällige Salts im Backend (Cloud) und verteilt diese an die Edge-Geräte. Ein Salt ist ein Zufallswert, der als Eingabe für das Hashing von Daten verwendet wird, z.B. von Passwörtern oder in unserem Fall eben von Nummernschildern. Dieser Zufallswert wird nicht im Backend gespeichert. Lediglich im Edge-Gerät, also etwa in der Perception Box, werden die Salts kurzzeitig zwischengespeichert.

Um die Sicherheit vor potentiellen Angriffen zu gewährleisten und zu erhöhen, hat ein Salt ein Gültigkeitsfenster von zwölf Stunden. Nach Ablauf dieser wird ein neues, zufällig generierter Salt verwendet. Die folgende Grafik zeigt ein Beispiel für die Hashing-Funktion, die für die Kennzeichen verwendet wird:

Die vier Salts werden vom Salt Shaker erzeugt und an jedes Edge-Gerät verteilt. Um immer alle Fahrten zu erfassen, wird jedes Kennzeichen mit zwei Salts gehasht. Grund dafür ist die Annahme, dass eine Fahrt potentiell länger dauern kann als die Gültigkeitsdauer eines Salts. Weitere Informationen dazu folgen im nächsten Abschnitt.

Event wird ausgelöst und gesendet

Wenn das Fahrzeug eine Counting Line überfährt, wird ein entsprechend Event mit den Hashes der erkannten Nummernschilder über MQTT an die Cloud (Microsoft Azure) gesendet und in einer strukturierten Datenbank gespeichert.

Abgleichen/Matching der Journey Times

In der Cloud wird die Datenbank regelmäßig auf mögliche Übereinstimmungen innerhalb des Hashes überprüft. Wie bereits erläutert, werden pro erkanntem Fahrzeug zwei Hashes erstellt. Wenn einer der beiden bei zwei verschiedenen Erkennungen identisch ist, wird er als eine Fahrt mit den entsprechenden Fahrtzeitinformationen, der Fahrzeugklasse, den Namen des Edge-Geräts und den GPS-Koordinaten des Edge-Geräts gespeichert.

Falls derselbe Hash an mehreren Orten gefunden wird, wird eine sogenannte Multi-Hop-Fahrt basierend auf der Sortierung der Zeitstempel gespeichert (z.B. Fahrt von Ort A nach B nach C).

Anonymisierung der Daten

Nach zwölf Stunden, also der Gültigkeitsdauer des zur Pseudonymisierung des Kennzeichens verwendeten Salts, wird das pseudonymisierte Kennzeichen gelöscht. Durch diesen Vorgang werden die pseudonymisierten Daten entsprechend anonymisiert. Zusammengefasst bedeutet dies, dass nach zwölf Stunden nach der Erkennung des Fahrzeugs und des Kennzeichen sämtliche Daten anonymisiert sind.

Salt-Hashing-Funktion
Das Fahrzeug wird erkannt
Das Kennzeichen wird erkannt
Lesen des Kennzeichens
Hashing-Prozess mit Salt Shaker
Das Event wird ausgelöst.
Das Event wird dann vom Edge-Gerät in die Cloud übertragen.
Zuweisung der Journey Time