Integration – technische Übersicht

Die Alarme der Überwachungssysteme von Reconeyez können über verschiedene Überwachungsprogramme, die Sicherheitsexperten verwenden, überwacht werden. Die Integration von Überwachungsstationen Dritter erfolgt auf Serverebene, d. h., dass die installierten Geräte Alarme an den ausgewählten Reconeyez-Server senden und dieser die empfangenen Alarme und Statusereignisse an die Überwachungsstationen weiterleitet.

Unterstützte Integrationstypen

• E-Mail (Mensch)
• Immix
• Sentinel
• Patriot
• SIA DC-09.2021 (inkl. ADM-CID und SIA-DCS)
• Surgard Automation Output Protocol (inkl. SIA Protocol 2)
• Accellence EBÜS
• Bold Group Manitou

Unterstützte Übertragungsprotokolle

Für Ereignis- und visuelle Verifikationsübertragung verwendet Reconeyez SMTP, TCP/IP und FTP(ES) Protokolle.

• SMTP (E-Mail, Immix, Sentinel, Patriot)
  – mit STARTTLS
• TCP/IP (SIA DC-09-2021, Surgard und Manitou)
  – mit dauerhafter Verbindung (verwendet von Surgard AOP)
  – mit TLS (verwendet von Surgard AOP)
    mit FTP (SIA DC-09-2021 mit Foto hochgeladen mittels FTP)
• FTP (EBÜS)
  – ftps (verwendet explizit FTP + TLS, auch bekannt als FTPES)
  

Unterstützte Ereignistypen

Systemereignisse

Systemereignisse benachrichtigen den Status der Reconeyez-Integrationskomponente.

Alarmereignisse
Alarmereignisse stammen direkt von den physikalischen Geräten vor Ort.

• Bewegungsalarme
• Sabotage-/Diebstahlalarme
• Routineprüfungen
• kritisches Herunterfahren des Akkus
• [Bridge IO] Deckel geöffnet
• [Bridge IO] Hilfsstromversorgung verloren/gefunden
• [Bridge IO] interne Akkuladung fehlerhaft/normal
  
  

Überwachungsereignisse
Überwachungsereignisse werden wie im Protokoll des entsprechenden Integrationstyps definiert verwendet und implementieren das im entsprechenden Protokoll definierte Format. Überwachungsbenachrichtigungen werden in SIA DC-09-2021, Surgard AOP und Bold Manitou-Protokollen unterstützt. 

Statusereignisse
Statusereignisse spiegeln den Status einzelner Geräte auf dem Reconeyez-Server wieder.

• Verbindung verloren/wiederhergestellt
• Akkustand niedrig/wiederhergestellt
• Gerät scharf/unscharf
  

Ereignisse können gefiltert werden nach

• automatischen Alarmen (Person, Auto, Lkw, Fahrrad, Motorrad – erkannt vom AD-Algorithmus)
• Routineprüfungen (stündlich/täglich nach Gerätetyp)
• Statusereignissen (nach Statusereignistyp: Akku, Scharfstellung, Verbindung)

Ereignis- und Geräte-Metadaten

Die propagierten Geräte- oder Ereignis-Metadaten hängen von den spezifischen Möglichkeiten des Integrationstyp-Formats ab. Weitere Informationen über weitergeleitete Metadaten finden Sie in der technischen Dokumentation des jeweiligen Integrationstyps.

Zurzeit stehen folgende Daten zur Weiterleitung zur Verfügung:

1. Gerät – Geräte-GUID
2. Name – Detektor/Bridge und Kurz-ID
3. Bereich – Site-Name/Standort-Name
4. Beschreibung – jede Beschreibung, die sich auf das Gerät bezieht, wird auch in integrierten Systemen verwendet, um eine Verbindung zu einer bestimmten Gerätegruppe oder einem Standort herzustellen (d. h.: Immix:S12345, Sentinel:12345, Patriot:0011-01)
5. Ereignistyp (konvertiert in Integrationstyp-spezifische Ereignistypen)
6. Erkannte Akteure – Person, Auto, Auto, Lkw, Bus, Motorrad, Fahrrad, Boot
7. Zeitstempel – Zeitpunkt des Alarms in der Zeitzone des Geräts
8. URL – Link zur Reconeyez-Cloud, wo Benutzern Fotos in voller Größe, Objekterkennungen, Sirenen usw. angezeigt werden
9. Geräteakku – Akkustand in %
10. Standort – GPS-Koordinaten
11. Signalstärke – ASU (https://en.wikipedia.org/wiki/Mobile_phone_signal#ASU)
12. Angehängtes/hochgeladenes Foto oder Video (1 PIR Trigger × N Bilder (standardmäßig 1 Trigger – 1 Foto)). (Vorschaubild-Qualität ~10–20 kB).

Verbindungssicherheit

Für jede Verbindung sollte Ende-zu-Ende-Verschlüsselung verwendet werden. TLS sollte für TCP und STARTTLS für SMTP- und FTP-Verbindungen verwendet werden.

Falls im zentralen Stations-Server selbstsignierte Zertifikate verwendet werden, benötigt Reconeyez die vollständige Zertifikatskette einschließlich des Zertifikats der Zertifizierungsstelle (CA), um es in unserem Verzeichnis vertrauenswürdiger Zertifikate zu hinterlegen.

Verbindungsredundanz

TCP/IP-Übertragungs-Fallback

IP-Fallback (auch bekannt als primäre und sekundäre Server-Verbindung) erlaubt das Konfigurieren einer sekundären IP-Adresse, auf die der Integrationsnachrichten-Dispatcher wechseln kann, falls die primäre IP-Verbindung fehlschlägt. Die Logik besteht darin, dass bei einer neuen Verbindung die primäre IP immer zuerst ausprobiert wird, die sekundäre IP aber erst, wenn die Verbindung zur primären IP nicht hergestellt werden kann. Die Verbindung läuft in einer zirkulären Schleife, bis eine Verbindung zu einer IP hergestellt ist. Tatsächlich ist die Anzahl der Fallback-IPs nicht auf 2 beschränkt – es können so viele wie nötig eingerichtet werden.

Derzeit ist die Funktion nur für TCP/IP-Übertragungstypen verfügbar.

FTP-Redundanz

Die FTP-Client-Implementierung der Integrationskomponenten erlaubt das Konfigurieren einer Liste von IP-Adressen oder Hostnamen mit einem Port. Die Hostnamen werden um alle IP-Adressen erweitert, die sie auflösen. Der Verbindungspool des Clients wählt im Rundlauf-Verfahren aus allen Adressen aus. Daher können die Dateien für ein und dasselbe Ereignis auf verschiedenen Hosts landen.

Bei der Festlegung mehrerer Hosts sollten diese identische Spiegel voneinander sein. Das bedeutet, dass die Hosts die gleichen Anmeldedaten akzeptieren müssen. Außerdem muss das verwendete Zertifikat die Identifizierung aller konfigurierten Hosts ermöglichen, wenn TLS für die Verschlüsselung Kommunikation verwendet wird. Der Hostname wird mit dem Inhaber- und dem Alternativnamen des Zertifikats abgeglichen. Wenn stattdessen eine IP-Adresse angegeben wird, muss die IP im Zertifikat innerhalb des Abschnitts für die Alternativnamen des Inhabers angegeben werden, um das Zertifikat erfolgreich zu validieren. Dies darf jedoch nicht als DNS-Eintrag erfolgen (z. B. Hostname), sondern stattdessen als IP.

Lastverteilung per DNS

Eine weitere Möglichkeit, die Verbindungsredundanz zu erreichen, ist das Hinzufügen mehrerer Host-Datensätze zum DNS. Die Clients sollten dann halbzufällig auf eine der vielen Adressen aufgelöst werden.

Visuelle Verifizierung

Reconeyez-Detektoren erfassen Fotos zur Alarmüberprüfung. Es werden Fotos aufgezeichnet, wenn der entsprechende Sensor Bewegungen oder Sabotage erkennt. Die Detektoren können so konfiguriert werden, dass bis zu 10 Fotos pro Erkennung erstellt werden. Standardmäßig sind sie auf 1 Foto eingestellt, da dies die optimale Konfiguration ist. Die Integrationskomponente kann die Fotos als separate JPG-Dateien verschicken oder einen Videoclip der Sequenz im MJPEG- oder AVI-Format zusammenstellen. Abhängig vom Integrationstyp wird die visuelle Verifizierungsdatei vor oder zusammen mit der Ereignisnachricht angehängt, hochgeladen oder übertragen. 

Reverse Control

Überwachungsprogramme von Drittanbietern, die vollständig in das Reconeyez-System integriert wurden, unterstützen auch die Rückwärtssteuerung. Es ist verfügbar, eine HTTP REST API für diesen Zweck zu verwenden. Dies beinhaltet das Abrufen der Geräteliste, das Aktivieren der Reconeyez-Sirenen und das Scharfstellen/Unscharfstellen der Geräte. Es können zusätzliche Funktionen hinzugefügt werden. Reverse-Control-HTTP-Anfragen müssen an denselben Reconeyez-Server gesendet werden, der für Ihre Bridge konfiguriert ist, abgesehen vom Server uk.reconeyez.com. In diesem Fall müssen die Anfragen an https://integrations.reconeyez.com gesendet werden.Derzeit wurde Reverse Control in der folgenden Kapazität implementiert:

Immix
– Auslösen des Reconeyez-Sirenentons

Sentinel
– Auslösen des Reconeyez-Sirenentons
– Scharstellen/Unscharfstellen der Reconeyez-Geräte

EBÜS
– Auslösen des Reconeyez-Sirenentons
– Scharstellen/Unscharfstellen der Reconeyez-Geräte