Zum Inhalt springen
Kontakt

Kundenprojekt · IoT · On-Premises

Plattform für Feldgeräte-Daten: Live ausgewertet. Im eigenen Haus.

Eine IoT-Plattform, die nicht in einer fremden Cloud läuft, sondern direkt im Rechenzentrum des Kunden. Die Geräte melden ihre Messwerte per MQTT an einen eigenen Broker. Eine Laravel-Anwendung wertet sie in Echtzeit aus und zeigt dem Service, welches Gerät Aufmerksamkeit braucht.

Ähnliches Projekt besprechen Der Weg eines Messwerts

Steckbrief

Kunde
Hersteller von Messtechnik
Betrieb
On-Premises, im Rechenzentrum des Kunden
Technologien
  • Laravel
  • Livewire
  • MQTT-Broker
  • Redis
  • On-Premises

Datenfluss

Schematische Darstellung

Feldgeräte

  • Gerät 01
  • Gerät 02
  • Gerät 03
  • Gerät 04

Rechenzentrum des Kunden

MQTT-Broker

nimmt die Messwerte an

Auswertung in Echtzeit

Laravel-Anwendung

Alarm für Gerät 03

Service-Ansicht

  • Gerät 01 in Ordnung
  • Gerät 02 in Ordnung
  • Gerät 03 braucht Aufmerksamkeit
  • Gerät 04 in Ordnung

Keine Daten bei Drittanbietern

Cloud eines Drittanbieters keine Daten

Schematische Darstellung: Gerätenummern, Nachrichten und Zustände sind erfunden. Sie zeigen das Prinzip, nicht Daten oder Aufbau beim Kunden.

Das Bild zeigt den Weg schematisch. Feldgeräte melden ihre Messwerte per MQTT an einen eigenen Broker, eine Laravel-Anwendung wertet sie in Echtzeit aus, und die Service-Ansicht markiert das Gerät, das Aufmerksamkeit braucht, hier Gerät 03. Die Plattform läuft im Rechenzentrum des Kunden. Die Cloud eines Drittanbieters bekommt keine Daten.

Das Projekt

Aus dem Feld ins eigene Rechenzentrum. In Echtzeit.

elsyQ hat die Plattform für einen Hersteller von Messtechnik gebaut. Das Ergebnis passt in drei Punkte. Was hinter den Begriffen steckt, erklären die Abschnitte weiter unten.

Der Weg eines Messwerts

Ein Messwert auf Reisen: vom Feldgerät bis zum Service.

MQTT entkoppelt Sender und Empfänger. Ein Gerät schickt seine Nachricht an den Broker, und der Broker reicht sie an jeden Client weiter, der ein passendes Abonnement hat. Das Gerät muss nicht wissen, wer mitliest.

Ein Messwert, Station für Station

Beispiel

  1. Gerät

    Das Gerät veröffentlicht

    Das Gerät schickt eine Nachricht an den Broker. Sie trägt ein Topic, also einen Pfad aus Ebenen, und die Nutzdaten.

    Topic
    tenant-a/site-1/device-03/reading
    Nutzdaten
    {
    "device": "device-03",
    "value": 80.9
}

    MQTT schreibt kein Format für die Nutzdaten vor. JSON ist hier nur ein Beispiel.

  2. Broker

    Der Broker verteilt

    Der Broker vergleicht das Topic mit den Abonnements seiner Clients und reicht die Nachricht an jeden weiter, dessen Abonnement passt.

    Abonnement tenant-a/+/+/reading passt auf tenant-a/site-1/device-03/reading

  3. Laravel-Anwendung

    Die Anwendung wertet aus

    Die Laravel-Anwendung wertet die Messwerte in Echtzeit aus. Im Beispiel prüft eine einfache Regel eine Obergrenze.

    Beispielregel: Alarm über 80 %, Ende erst bei 75 % oder darunter

    Messwert 80,9 % liegt über 80 %.

  4. Laravel-Anwendung

    Ein Alarm entsteht

    Im Beispiel liegt der Wert über der Grenze. Daraus wird ein Alarm für den Service, und er bleibt aktiv, bis der Wert wieder tief genug liegt.

    Gerät
    03
    Wert
    80,9 %
    Grenze
    80 %
    Zustand
    aktiv

  5. Service

    Der Service sieht es

    Die Anwendung zeigt dem Service, welches Gerät Aufmerksamkeit braucht. Aus einem Messwert ist ein Hinweis geworden, mit dem jemand etwas anfangen kann.

    Gerät 03 braucht Aufmerksamkeit

Beispiel: Topic, Nutzdaten, Abonnement und Regel sind ausgedacht. Sie zeigen, wie ein Messwert über MQTT laufen kann, nicht wie die Anbindung im Projekt gebaut ist.

MQTT, kurz erklärt

Broker

Der Server, über den alle Nachrichten laufen. Geräte und Anwendungen verbinden sich mit ihm, nicht direkt miteinander.

Publish und Subscribe

Wer sendet, veröffentlicht unter einem Topic. Wer empfangen will, abonniert Topics. Sender und Empfänger müssen einander nicht kennen.

Wenig Overhead

MQTT wurde für Geräte mit wenig Rechenleistung und für unzuverlässige Netze entworfen. Der feste Kopf einer Nachricht braucht nur zwei bis fünf Byte, und jeder Client hält eine einzige Verbindung zum Broker.

Topics und Abonnements

Beispiel

Ein Topic ist ein Pfad aus Ebenen, getrennt durch Schrägstriche. Ein Abonnement darf Platzhalter enthalten: Das + steht für genau eine Ebene. Das # darf nur am Ende stehen und erfasst beliebig viele Ebenen ab dieser Stelle, auch keine.

Aufbau des Beispiel-Topics

  1. tenant-a Mandant
  2. site-1 Standort
  3. device-03 Gerät
  4. reading Art der Nachricht
Welche Beispiel-Topics die drei Abonnements erfassen
Topic Filter 1 tenant-a/+/+/reading Filter 2 tenant-a/site-1/# Filter 3 +/+/device-03/#
tenant-a/site-1/device-01/reading passt passt passt nicht
tenant-a/site-1/device-03/reading passt passt passt
tenant-a/site-2/device-04/reading passt passt nicht passt nicht
tenant-a/site-1/device-03/status passt nicht passt passt
tenant-b/site-1/device-11/reading passt nicht passt nicht passt nicht
tenant-b/site-1/device-13/status passt nicht passt nicht passt nicht

Die Hierarchie ist ausgedacht und zeigt nur das Prinzip. MQTT legt lediglich fest, dass Ebenen durch Schrägstriche getrennt sind; wie sie heißen und in welcher Reihenfolge sie stehen, entscheidet jedes System selbst.

Drei Stufen der Zustellung

Wie verlässlich eine Nachricht ankommt, legt bei MQTT die Quality of Service fest, kurz QoS. Mehr Verlässlichkeit kostet mehr Pakete.

QoS 0

höchstens einmal

  1. PUBLISH

    vom Sender zum Empfänger

Einmal gesendet, ohne Bestätigung. Reißt die Verbindung ab, kann die Nachricht fehlen.

QoS 1

mindestens einmal

  1. PUBLISH

    vom Sender zum Empfänger

  2. PUBACK

    vom Empfänger zum Sender

Der Sender hebt die Nachricht auf, bis PUBACK kommt, und schickt sie nach einem Verbindungsabbruch noch einmal. Sie kann deshalb doppelt ankommen.

QoS 2

genau einmal

  1. PUBLISH

    vom Sender zum Empfänger

  2. PUBREC

    vom Empfänger zum Sender

  3. PUBREL

    vom Sender zum Empfänger

  4. PUBCOMP

    vom Empfänger zum Sender

Vier Pakete in zwei Runden. Mit PUBREC bestätigt der Empfänger den Eingang und merkt sich die Paketkennung. Mit PUBREL gibt der Sender die Nachricht frei, und PUBCOMP schließt den Austausch ab. Kommt die Nachricht wegen einer Wiederholung zweimal an, erkennt der Empfänger sie an der Kennung und stellt sie nur einmal zu. Das ist die aufwendigste Stufe.

Die Stufe gilt je Strecke: vom Absender zum Broker und vom Broker zu jedem Abonnenten. Ein Abonnent bekommt höchstens die Stufe, mit der er abonniert hat. Wiederholt wird bei QoS 1 und 2 nur, wenn die Sitzung den Verbindungsabbruch überdauert. Das alles gilt für MQTT allgemein; welche Stufen das Projekt nutzt, nennt diese Seite nicht.

Echtzeit-Auswertung und Alarme

Live ausgewertet. Alarm, sobald ein Gerät Aufmerksamkeit braucht.

Die Laravel-Anwendung wertet die Messwerte in Echtzeit aus, und für den Service gibt es Alarme. Wie eine Alarmregel zum Beispiel aussehen kann, zeigt die Illustration darunter: eine Obergrenze mit Hysterese.

Warum Hysterese

Pendelt ein Wert knapp um die Grenze, schaltet eine einfache Regel den Alarm ständig ein und aus, und wer die Alarme bearbeitet, bekommt eine Meldung nach der anderen. Mit Hysterese endet ein Alarm erst, wenn der Wert um einen festen Abstand unter die Grenze gefallen ist. Aus einer Serie von Alarmen wird so einer.

Vier Beispielgeräte, eine Grenze

Illustration · synthetische Daten

Alarme für den Service

  1. Gerät 03: Alarm seit Messung 82, Spitze 90,8 %, noch aktiv

Grenzwert 80 %, Hysterese 5 Prozentpunkte. Alarme im ganzen Verlauf: 1, davon aktiv: 1.

Alarme im ganzen Verlauf je Grenzwert, mit und ohne Hysterese
Grenzwert mit Hysterese ohne Hysterese
70 % 3 7
75 % 3 5
80 % 1 3
85 % 1 8
90 % 2 2

Vier Beispielgeräte liefern je 120 synthetische Messwerte. Gerät 03 steigt ab Messung 61 an, überschreitet bei Messung 82 den Grenzwert von 80 % und bleibt bis zum Ende im Alarm, mit einer Spitze von 90,8 %. Gerät 02 kommt bis auf 78,2 % heran, ohne den Grenzwert zu überschreiten. Alarme mit Hysterese: 1, ohne Hysterese: 3.

Illustration mit synthetischen Daten: 120 Messwerte je Gerät, erzeugt aus einer festen Formel. Die Grenzwertregel ist ein Lehrbeispiel und nicht die Alarmlogik des Projekts.

Betrieb im eigenen Haus

Eigenes Rechenzentrum, eigene Daten, keine fremde Cloud.

On-Premises heißt allgemein: Software läuft auf Servern, die ein Unternehmen selbst betreibt, und nicht bei einem Cloud-Anbieter. Genau so läuft diese Plattform, im Rechenzentrum des Kunden.

Was im Haus liegt

Schematische Darstellung

Im Feld

Feldgeräte, die per MQTT melden

Rechenzentrum des Kunden

  • Eigener MQTT-Broker
  • Laravel-Anwendung mit Echtzeit-Auswertung
  • Messwerte und Alarme
  • Rollen, Mandanten und Audit-Trail

Außerhalb

Cloud eines Drittanbieters

keine Daten

Schematische Darstellung aus den Eckdaten des Projekts, kein Netzplan.

On-Premises, allgemein

Wer entscheidet

Wer selbst betreibt, bestimmt, wo die Daten liegen und wer darauf zugreift. Auch den Zeitpunkt jedes Updates legt der Betreiber fest.

Wer die Arbeit hat

Was sonst ein Cloud-Anbieter übernimmt, liegt beim Betreiber: Updates, Datensicherung, Überwachung. Das gehört von Anfang an in die Planung.

Was es nicht heißt

On-Premises heißt nicht abgeschottet. Geräte im Feld müssen die Server im Rechenzentrum trotzdem erreichen, und dieser Weg will geplant sein.

Die drei Punkte gelten für On-Premises allgemein. Wie Netz und Betrieb im Projekt aussehen, gehört nicht auf eine öffentliche Seite.

Rollen, Mandanten, Audit-Trail

Rollen und Mandanten trennen, wer was sieht. Der Audit-Trail schreibt mit.

Die Plattform ist rollen- und mandantenfähig und führt einen Audit-Trail. Was die drei Begriffe allgemein bedeuten:

Rolle
Legt fest, was ein Benutzer tun darf, zum Beispiel nur ansehen oder auch verwalten.
Mandant
Ein Kunde oder Bereich, dessen Daten in derselben Installation von denen aller anderen getrennt bleiben.
Audit-Trail
Ein Protokoll, wer wann was getan hat. In der Regel werden Einträge nur angehängt und nie geändert.

Gleiche Anwendung, andere Sicht

Illustration · Beispieldaten
Geräte je Mandant
Gerät Mandant Zustand
Gerät 01 Mandant A in Ordnung
Gerät 02 Mandant A in Ordnung
Gerät 03 Mandant A braucht Aufmerksamkeit
Gerät 04 Mandant A in Ordnung
Gerät 11 Mandant B in Ordnung
Gerät 12 Mandant B in Ordnung
Gerät 13 Mandant B in Ordnung
Rechte je Rolle
Recht Service Administration
Geräte und Messwerte ansehen erlaubt erlaubt
Alarme sehen erlaubt erlaubt
Benutzer und Rollen verwalten nicht erlaubt erlaubt
Audit-Trail einsehen nicht erlaubt erlaubt

Audit-Trail

  1. Nr. 141 07:58 Mandant A Administration Rolle Service zugewiesen
  2. Nr. 142 08:03 Mandant A Service Anmeldung
  3. Nr. 87 08:11 Mandant B Service Anmeldung
  4. Nr. 143 08:17 Mandant A System Alarm für Gerät 03 ausgelöst
  5. Nr. 144 08:40 Mandant A Administration Grenzwert für Gerät 02 geändert
  6. Nr. 88 08:52 Mandant B Administration Rolle Service zugewiesen

Illustration mit erfundenen Daten. Rollen und Rechte sind Beispiele, nicht die des Projekts. Die Einträge sind je Mandant fortlaufend nummeriert: Fehlt eine Nummer, fällt es sofort auf.

Technik

Fünf Bausteine, eine Plattform. Jeder kurz erklärt, und wo die Eckdaten etwas über seinen Einsatz im Projekt sagen, steht es dabei.

Laravel

Ein PHP-Framework für Webanwendungen. Routing, Datenbankzugriff, Anmeldung und Rechteprüfung bringt es bereits mit.

Im Projekt Die Laravel-Anwendung wertet die Messwerte in Echtzeit aus und zeigt dem Service, welches Gerät Aufmerksamkeit braucht.

Livewire

Ein Framework für Laravel, mit dem interaktive Oberflächen aus PHP-Komponenten entstehen statt aus einem eigenen JavaScript-Frontend. Bei einer Aktion im Browser rendert der Server die Komponente neu, und Livewire tauscht nur die geänderten Teile der Seite aus.

Teil des Technik-Stacks

MQTT-Broker

Der Server im Publish-Subscribe-Protokoll MQTT. Er nimmt Nachrichten an und verteilt sie an die Clients, die ihr Topic abonniert haben.

Im Projekt Der eigene Broker, an den die Geräte ihre Messwerte melden.

Redis

Ein Datenspeicher, der Schlüssel und Datenstrukturen im Arbeitsspeicher hält und sie auf Wunsch zusätzlich auf Datenträger sichert.

Teil des Technik-Stacks

On-Premises

Software läuft auf Servern, die das Unternehmen selbst betreibt, statt bei einem Cloud-Anbieter.

Im Projekt Die Plattform läuft im Rechenzentrum des Kunden, nicht in einer fremden Cloud.

Von der Weboberfläche bis zur Firmware

Unabhängig von diesem Projekt baut elsyQ die ganze Kette zwischen Web und Hardware: Weboberfläche und API in Laravel, Anbindung über MQTT oder OPC UA und die Firmware auf dem Gerät.

  1. Weboberfläche und API

    Laravel

  2. Anbindung

    MQTT · OPC UA

  3. Firmware

    auf dem Gerät

Alle Projekte ansehen

Häufige Fragen

Was ist die Plattform für Feldgeräte-Daten?

Die Plattform für Feldgeräte-Daten ist ein Kundenprojekt von elsyQ für einen Hersteller von Messtechnik: eine IoT-Plattform, die nicht in einer fremden Cloud läuft, sondern direkt im Rechenzentrum des Kunden. Die Geräte melden ihre Messwerte per MQTT an einen eigenen Broker. Eine Laravel-Anwendung wertet sie in Echtzeit aus und zeigt dem Service, welches Gerät Aufmerksamkeit braucht.

Was bedeutet On-Premises bei dieser Plattform?

Die Plattform, die elsyQ für einen Hersteller von Messtechnik gebaut hat, läuft im Rechenzentrum des Kunden und nicht in der Cloud eines Drittanbieters. Der Betrieb liegt vollständig im eigenen Haus, Daten landen bei keinem Drittanbieter. Allgemein heißt On-Premises, dass Software auf Servern läuft, die ein Unternehmen selbst betreibt.

Wie kommen die Messwerte in die Plattform?

Bei der Plattform, die elsyQ gebaut hat, melden die Geräte ihre Messwerte per MQTT an einen eigenen Broker. Allgemein arbeitet MQTT nach dem Publish-Subscribe-Prinzip: Ein Gerät veröffentlicht eine Nachricht unter einem Topic, und der Broker reicht sie an die Clients weiter, die dieses Topic abonniert haben.

Was ist MQTT, und was macht der Broker?

MQTT ist ein schlankes Publish-Subscribe-Protokoll, über das elsyQ Geräte an Anwendungen anbindet. Geräte und Anwendungen sprechen nicht direkt miteinander, sondern über einen Broker: Er nimmt Nachrichten an und verteilt sie nach Topics an die Abonnenten. Wie verlässlich eine Nachricht ankommt, legt die Quality of Service fest, von höchstens einmal bis genau einmal.

Wie erfährt der Service, welches Gerät Aufmerksamkeit braucht?

In der Plattform, die elsyQ gebaut hat, wertet eine Laravel-Anwendung die Messwerte in Echtzeit aus und zeigt dem Service, welches Gerät Aufmerksamkeit braucht. Dazu gehören Alarme für den Service. Die Regel mit Grenzwert und Hysterese auf dieser Seite ist eine Illustration mit synthetischen Daten und nicht die Alarmlogik des Projekts.

Was heißt rollen- und mandantenfähig mit Audit-Trail?

Die Plattform, die elsyQ für einen Hersteller von Messtechnik gebaut hat, ist rollen- und mandantenfähig und führt einen Audit-Trail. Allgemein heißt das: Rollen legen fest, was ein Benutzer tun darf. Mandanten sind Kunden oder Bereiche, deren Daten in derselben Installation getrennt bleiben. Ein Audit-Trail hält fest, wer wann was getan hat.

Mit welchen Technologien ist die Plattform gebaut?

elsyQ hat die Plattform mit Laravel und Livewire gebaut, dazu kommen ein MQTT-Broker und Redis. Betrieben wird alles On-Premises, im Rechenzentrum des Kunden. Laravel ist ein PHP-Framework für Webanwendungen, mit Livewire entstehen darauf interaktive Oberflächen aus PHP-Komponenten, und Redis ist ein Datenspeicher, der seine Daten im Arbeitsspeicher hält.

Baut elsyQ so eine Plattform auch für andere Geräte?

elsyQ baut Plattformen für Gerätedaten auch für andere Geräte. Unabhängig von diesem Projekt deckt elsyQ die ganze Kette zwischen Web und Hardware ab: Weboberfläche und API in Laravel, Anbindung über MQTT oder OPC UA und die Firmware auf dem Gerät. Ob eine Plattform im eigenen Rechenzentrum oder in einer Cloud laufen soll, klären wir mit Ihnen am Anfang des Projekts.

Markenhinweis Genannte Namen Dritter (Laravel, Livewire, Redis, OPC UA) sind Kennzeichen ihrer jeweiligen Inhaber und bezeichnen hier nur Software oder Standards. elsyQ ist von diesen Inhabern unabhängig.

Zusammenarbeit

Messwerte Ihrer Geräte, ausgewertet dort, wo Sie es wollen?

Erzählen Sie uns, welche Geräte Sie haben und was der Service sehen soll. Wir sagen Ihnen, wie wir es bauen würden.

Ähnliches Projekt besprechen Alle Projekte