Unser Universal Gateway zum Datenaustausch von unterschiedlichen netzwerkbasierten und seriellen Kommunikationsprotokollen der Industrie- und Gebäudeautomation inkl. Datenspeicherung fungiert als Datenvermittler zwischen unterschiedlichen Quellen und Senken.
Das Universal Gateway ist so gestaltet, dass es grundsätzlich jedes beliebige Kommunikationsprotokoll (falls noch nicht implementiert, machen wir das gerne als spezifischen Kundenauftrag) verarbeiten kann.
Unsere dazu Made in Austria entwickelte Gateway-Software ist grundsätzlich auf jedem Linux basierenden Rechner, auch auf Hutschienen-PCs, lauffähig. Je nachdem ob Vorortdaten als Backup gespeichert werden oder wie viele Prozesse parallel ablaufen sollen, ändert sich die Anforderung an den Hardwarebedarf. Die Software muss eventuell ein wenig auf die gewünschte individuelle Hardware angepasst werden.
Derzeit implementierte Protokolle:
Modbus TCP/IP Client und Server
MBus-TCP/IP Client (MBUS-TCP/IP Server auf Anfrage)
JSON-Rest-API Client und Server (Verschlüsselung: HTTPS oder OPEN VPN)
SNMP v2 Server (SNMPv3 auf Anfrage)
NTP Client
Vorort-Backupspeicherung im CSV-Format
Technische Möglichkeiten
M-Bus:
Es besteht die Möglichkeit bis zu 3 M-Bus Segmente gleichzeitig (abhängig von der Hardware) auszulesen. Dies bedeutet der Stromzähler, Wasserzähler als auch der Gaszähler einer Anlage kann zeitgleich ausgelesen werden ohne Zeitversatz. Nach dem Einlesen bekommen die Daten einen internen Zeitstempel (UTC) & Anlagennummer. Somit ist der Übertragungszeitpunkt zu einer möglichen Energiedatenauswertungszentrale nicht mehr kritisch, da die Daten anhand des Zeitstempels & Anlagennummer sortiert werden können. Über NTP wird die Zeit immer aktuell gehalten.
Die Daten können (gefiltert, auszugsweise, umgewandelt (z.B. Einheiten) etc.),
- via Modbus-Server anderen Teilnehmer zur Verfügung gestellt werden.
- im CSV-Format vor Ort abgespeichert werden und mittels SFTP oder FTPS zu einem beliebigen Teilnehmer (nach Anforderung, automatisch etc.) übertragen werden.
- Über eine JSON-Rest-API Schnittstelle an einen Teilnehmer übertragen werden.
Die MBUS-Teilnehmer können
- als virtuelle Geräte mit SNMPv2 Funktionen dargestellt werden. Eine Störmanagement-Zentrale kann somit z.B. die Nichterreichbarkeit eines M-BUS-Teilnehmers registrieren.
Der über MBUS-TCP/IP angeschlossene MBUS-Master kann ebenso als virtuelles Gerät mit SNMPv2 Funktion dargestellt werden. Eine Störmanagement-Zentrale kann somit z.B. die Nichterreichbarkeit des M-Bus Masters und einen Kurzschluss auf der 2 Drahtleitung des M-Busses registrieren.
Modbus Client:
Es besteht die Möglichkeit bis zu 5 Modbus TCP/IP Clients (abhängig von der Hardware) sequenziell laufen zu lassen. Nach dem Einlesen bekommt der Messwert einen internen Zeitstempel (UTC) & Anlagennummer somit ist der Übertragungszeitpunkt zu einer möglichen Energiedatenauswertungszentrale nicht mehr kritisch, da die Daten anhand des Zeitstempels & Anlagennummer sortiert werden können. Über NTP wird die Zeit immer aktuell gehalten.
Die Daten können (gefiltert, auszugsweise, umgewandelt (z.B. Einheiten) etc.),
- via Modbus-Server anderen Teilnehmer zur Verfügung gestellt werden.
- im CSV-Format vor Ort abgespeichert werden und mittels SFTP oder FTPS zu einem beliebigen Teilnehmer (nach Anforderung, automatisch etc.) übertragen werden.
- über eine JSON-Rest-API Schnittstelle an einen Teilnehmer übertragen werden.
Die Modbus-Teilnehmer können
- als virtuelle Geräte mit SNMPv2 Funktionen dargestellt werden. Eine Störmanagement-Zentrale kann somit z.B. die Nichterreichbarkeit des Modbus-Servers registrieren.
Einzelne Modbus-Register können als virtuelle Geräte mit SNMPv2 Funktionen dargestellt werden. Eine Störmanagement-Zentrale kann somit z.B. eine Überlast oder Unterfunktion gewisser Werte (z.B. Durchfluss, Stromwerte, Leistungswerte) registrieren.
Modbus Server:
Es besteht die Möglichkeit bis zu 3 Modbus TCP/IP Server (abhängig von der Hardware) laufen zu lassen.
Die Daten, welche über MBUS, Modbus, JSON-Rest-API eingelesen wurden, können anderen Teilnehmern (gefiltert, auszugsweise, umgewandelt (z.B. Einheiten) etc.) via Modbus TCP/IP-Server zur Verfügung gestellt werden.
JSON-REST-API Client
Mit der JSON-REST-API-Client Kommunikationsschnittstelle kann von anderen Teilnehmern Daten gelesen werden.
Nach dem Einlesen bekommen die Daten einen internen Zeitstempel (UTC) & Anlagennummer somit ist der Übertragungszeitpunkt zu einer möglichen Energiedatenauswertungszentrale nicht mehr kritisch, da die Daten anhand des Zeitstempels & Anlagennummer sortiert werden können. Über NTP wird die Zeit immer aktuell gehalten.
Die Daten können (gefiltert, auszugsweise, umgewandelt (z.B. Einheiten) etc.),
- via Modbus-Server anderen Teilnehmer zur Verfügung gestellt werden.
- im CSV-Format vor Ort abgespeichert werden und mittels SFTP oder FTPS zu einem beliebigen Teilnehmer (nach Anforderung, automatisch etc.) übertragen werden.
- Über eine JSON-Rest-API Schnittstelle an einen Teilnehmer übertragen werden.
JSON-REST-API Server:
Daten, welche über MBUS, Modbus oder JSON-Rest-API eingelesen wurden, können anderen Teilnehmern (gefiltert, auszugsweise, umgewandelt (z.B. Einheiten) etc.) via JSON-REST-API-Server zur Verfügung gestellt werden.
SNMPv2
Teilnehmer oder deren Messstellen können als virtuelle Geräte mit SNMPv2 Funktion dargestellt werden. Unterstütze Befehle: GET-REQUEST; GET-RESPONSE
================================================================
Die Anforderungen und Wünsche in der Kommunikationsübersetzung sind so unterschiedlich wie unsere Kombinationsmöglichkeiten der Gateway-Software. Daher werden die Geräte auf die Kundenbedürfnisse individuell vorkonfiguriert ausgeliefert.
Eine nachträgliche Anlagenkonfigurationsänderung oder Funktionsänderung kann dann vor Ort oder, wenn vorhanden, via Fernwartung durchgeführt werden. Eine Zusammenarbeit zwischen Ihnen als Auftraggeber und uns als Dienstleister ist unumgänglich.
Wir freuen uns, wenn Sie uns kontaktieren, um mit Ihnen gemeinsam eine Lösung für Ihre individuelle Kommunikationsanforderung zu entwickeln.