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
  • Custom-MQTT-Broker
  • Komprimierung der Messages (Message Compression)
  • Event-Schema von Swarm
  • Event: Counting Line (CL)
  • Event: Region of Interest (RoI)
  • Rule-Event
  • Raw-track-Event (Heatmap)
  • Die Klassen im Event-Schema von Swarm

Was this helpful?

Export as PDF
  1. Swarm Control Center
  2. Datenintegration

Rohdaten via Custom-MQTT-Server

So nutzen Sie Ihre benutzerdefinierte MQTT-Verbindung.

PreviousData Analytics API (REST API)NextSwarm Control Center API

Last updated 1 year ago

Was this helpful?

Sobald Sie Ihren Anwendungsfall im Swarm Control Center konfiguriert haben, generiert unsere Software Events. Diese werden als Standard-JSON übertragen. Wenn Sie Data Analytics nicht nutzen und die Daten stattdessen lieber via abrufen möchten, bieten wir Ihnen die Möglichkeit, einen benutzerdefinierten MQTT-Broker zu konfigurieren.

Custom-MQTT-Broker

Die Swarm Perception Box sendet Events in Form eines JSON an einen von Ihnen konfigurierten MQTT-Broker. Für die Übertragung wird das verwendet. Falls Events nicht zugestellt werden können, z.B. aufgrund einer fehlenden Verbindung, werden Events bis zu 24.000 Messages gecacht.

Für noch höhere Sicherheit können Sie MQTT über SSL verwenden. Fügen Sie dafür einfach das Präfix ssl:// zur Broker-Konfiguration hinzu.

Komprimierung der Messages (Message Compression)

Wenn die Komprimierung konfiguriert ist, werden die Events mit zlib/inflate komprimiert:

Event-Schema von Swarm

Im unten verlinkten GitHub-Repository finden Sie das Event-Schema der verschiedenen Konfigurationstypen:



Event: Counting Line (CL)

Ein Counting-Line-Event wird ausgelöst, wenn ein Objekt besagte Counting Line überquert (identifiziert durch lineId). Diese Linie hat einen benutzerdefinierten Namen (lineName). Ein Zeitstempel (timestamp) wird gesetzt, wenn das Event auftritt. Das Objekt kann die Counting Line in zwei Richtungen überqueren (direction) und sich entweder hinein- (In) oder hinausbewegen (Out). Zusätzlich wird das Objekt, das die CL überquert, klassifiziert (class und subclass). Die Klassen hängen vom Anwendungsfall ab.

Wenn das ANPR-Feature aktiviert ist, werden die Kennzeichen (plateNumber) sowie das Herkunftsland des Kennzeichens (numberPlateOrigin) zum Event hinzugefügt.

ANPR wird benötigt, um Bilder der Kennzeichen bei Ein- und Ausfahrt zu machen. Die Kennzeichenbilder werden im JPG-Format an die MQTT-Message angehängt und mit BASE64 codiert.

Wenn Speed Estimation aktiviert sowie konfiguriert ist, gibt speedestimate die Ausgabe der Geschwindigkeitsschätzung in km/h an.


Event: Region of Interest (RoI)

Das Region-of-Interest-Event hängt vom Typ der RoI ab. Beispiel: Eine Region of Interest mit dem Typ Parking generiert ein ParkingEvent, während der Typ Generic ein RegionOfInterestEvent generiert:

ParkingEvent:

Dieses Event wird in einem Zeitintervall von zehn Sekunden ausgelöst. Die Informationen aller konfigurierten Parking-RoI werden in einem einzelnen Event aggregiert. In parkingSummary werden alle RoI mit der konfigurierten capacity und der aktuellen Anzahl der vehicles in der RoI selbst angezeigt.

Als Gesamtübersicht haben Sie dann totalCapacity und totalVehicles, die einen vollständigen Überblick über alle konfigurierten RoI mit dem Typ Parking in diesem Kamerastream geben. Zusätzlich besteht die Möglichkeit, ANPR für Parking-RoI zu aktivieren. Dadurch werden das Kennzeichen (plateNumber) sowie das Herkunftsland des Kennzeichens (numberPlateOrigin) im String-Format bereitgestellt.

RegionOfInterestEvent:

Ein RegionOfInterestEvent wird entweder durch eine Zustandsänderung oder ein bestimmtes Zeitintervall ausgelöst (triggerType). Der Zustand (state) kann von occupied to vacant oder umgekehrt wechseln. Occupied trifft zu, wenn die Anzahl der Objekte in der RoI mindestens so hoch ist wie zuvor als capacity konfiguriert.

Jedes Event enthält einen benutzerdefinierten Namen (roiName) und einen Zeitstempel (timestamp), wann das Event auftritt, bzw. aufgetreten ist. Erkannte Objekte und ihre zugeordneten Klassen sowie Verweilzeiten werden aufgelistet (objects). Die Klassen hängen vom Anwendungsfall ab.


Rule-Event

Wenn eine Regel für ein bestimmtes Ereignis angelegt wurde, wird ein entsprechendes Rule-Event gesendet. Dieses wird entsprechend basierend auf der gewählten Logik in Kombination mit den definierten Bedingungen ausgelöst. Ein Zeitstempel (timestamp) wird gesetzt, wenn das Event auftritt. Das Rule-Event enthält allgemeine Informationen zum Namen, zum Gerät und zur Stream-UUID. Darüber hinaus ist die gewählte gewählte, standardmäßige Eventinformation Teil der Message und im gleichen Format wie andere Messages für diese Eventtrigger.


Raw-track-Event (Heatmap)

In diesem Modus werden Objekte getrackt, während sie sich im Sichtfeld bewegen. Sobald das Objekt das Sichtfeld wieder verlassen hat, wird entsprechend die vollständige Route des Objekts generiert.

Der Raw Track enthält die Klassifizierung () und die Spur des Objekts durch das Sichtfeld. Die Klassen hängen vom Anwendungsfall ab.

Die Spur ist als eine Abfolge von path-Elementen definiert, die einen Zeitstempel sowie die Koordinaten enthalten. Die Koordinaten basieren auf dem Punkt der oberen linken Ecke kombiniert mit Breite und Höhe des jeweiligen Objekts. Pro Event gibt es maximal zehn path-Elemente. Zum besseren Verständnis der Berechnung der Koordinaten dient folgende Aufschlüsselung:

Die Klassen im Event-Schema von Swarm

Wie bereits erwähnt, enthält jedes Event eine Information zur Klasse/Klassifizierung des jeweiligen, erkannten Objekts. Zur besseren Übersicht haben wir in Klassen (class) und Unterklassen (sub class) aufgeteilt. Beispiele finden Sie hier:

Beispiel: Eine Counting Line erkennt einen Lieferwagen (van). Hinweis: Die class ist hier car, während die sub class van ist.

 "crossingLineEvent":{
      "class":"car",
      "subClass":"van",
      "direction":"in",
      "lineId":"test_id",
      "lineName":"office",
      "timestamp":"2019-12-29T10:31:14.373202Z"
   },

Es gibt mehrere Möglichkeiten, wie Sie ein JSON gegen ein Schema validieren können. Eine gute Übersicht bietet . Wir empfehlen außerdem als Online-Tool zur manuellen Validierung eines JSON gegen unser Schema.

Der Header des JSON wird durch eine Version des verwendeten Formats definiert (Propertyversion). Das Format ist major.minor, wobei eine Änderung der Hauptversion eine Änderung mit Abwärtskompatibilität darstellt. Für eindeutige Identifikatoren verlassen wir uns auf . Zeitstempel werden gemäß definiert.

Bitte kontaktieren Sie unseren , um Kennzeichenbilder via MQTT zu aktivieren.

json-schema.org
jsonschemalint.com
UUID
ISO8601
Support
Modelle
API
QoS Level
1
DeflateWikipedia
GitHub - hal9000-swarm/swarm-event-schema: Schema for generated MQTT eventsGitHub
Logo
Logo