Industrial IoT

Industrial IoT, das die Daten von der Maschine zu den Leuten bringt, die darauf reagieren.

Die meisten Anlagen haben die Signale längst, nur stecken die in Steuerungen, Zählern und Sensoren, die nie für ein Dashboard gedacht waren. Wir binden sie über Gateways an, verarbeiten das Wichtige am Edge und bauen Telemetrie-Pipeline, Dashboards und Alarme darauf, ohne die Steuerungslogik anzufassen.

Industrial-IoT-Projekt planen →

KURZ ERKLÄRT

Industrial IoT verbindet Maschinen und Feldsensoren mit Software, die ihre Daten speichert, auswertet und bei Abweichungen alarmiert. Dieser Auftrag umfasst Gateway-Anbindung (MQTT, OPC UA, Modbus), Edge-Verarbeitung, eine Telemetrie-Pipeline, Dashboards und Alarme für vereinbarte Anlagen.

Passt für

  • Werke und Außendienst-Betriebe, deren Maschinendaten in Steuerungen oder lokalen Panels festsitzen
  • Teams, die wissen, welches Signal zählt, und eine funktionierende Pipeline statt eines Plattform-Pitches brauchen

Eine andere Leistung passt besser

  • SPS-Programmierung, Firmware-Entwicklung oder Änderungen an sicherheitsrelevanter Steuerungslogik
  • Sensornetze von Städten und Versorgern auf LoRaWAN, dafür gibt es eine eigene Seite

Mit einer Linie, einer Maschinenklasse und einer Frage starten

Wähl Anlagen, bei denen ein fehlendes Signal echtes Geld kostet, etwa ungeplante Stillstände, Energieverbrauch oder eine Qualitätsdrift, die niemand rechtzeitig sieht. So bleibt der erste Umfang prüfbar. Baust du ein vernetztes Produkt, statt ein Werk anzubinden, starte bei Internet of Things. Kommunale Sensornetze und Versorger-Netze auf LoRaWAN gehören zu Smart City IoT.

Über Gateways anbinden, zuerst lesend

Industrienetze wurden für Steuerung gebaut, nicht für Analysen. Diese Grenze bleibt bestehen, und jeden schreibenden Zugriff vereinbaren wir mit der Person, die für die Anlage verantwortlich ist.

Protokolle über Gateways

OPC-UA-, Modbus- und andere Feldbusdaten über ein Industrie-Gateway oder eine bestehende SCADA-Schicht lesen und als MQTT veröffentlichen. Welche Protokolle und Geräte im Umfang sind, klären wir in der Analyse.

Standardmäßig nur lesend

Die Pipeline liest Werte. Jeder Befehl zurück an eine Maschine ist ein eigener, ausdrücklich vereinbarter Umfang mit der verantwortlichen Person, nie ein Nebeneffekt eines Dashboards.

Netzwerktrennung

Werksnetz und Cloud bleiben getrennt. Festlegen, welche Seite welche Verbindung öffnet, wie sich das Gateway authentifiziert und wer seine Konfiguration ändern darf.

Geräte- und Tag-Inventar

Jedes Signal einmal benennen, mit Einheit, Abtastrate und Quelle. Eine gemeinsame Tag-Liste verhindert, dass drei Dashboards drei Namen für denselben Sensor erfinden.

Am Edge verarbeiten, speichern, was du nutzt

Nicht jeder Wert gehört in die Cloud. Filterung, Aggregation und Pufferung am Edge halten Bandbreite und Speicherkosten planbar und überstehen einen Netzwerkausfall ohne Datenverlust. Danach werden Zeitstempel, Einheiten und Lücken geprüft, bevor Daten ein Dashboard erreichen. Soll die Telemetrie für Reports mit ERP-, Finanz- oder Vertriebsdaten verknüpft werden, wird diese Warehouse- und BI-Arbeit unter Data Engineering abgegrenzt.

Analysieren, pilotieren, dann erweitern

Jede Phase wird vor Beginn abgegrenzt und angeboten. Hardware, Gateways und Konnektivität werden separat aufgeführt, damit sie später keine Überraschung sind.

  1. Analyse

    Du bekommst ein Anlagen- und Signalinventar, Protokoll- und Gateway-Optionen, Netzwerk- und Zugriffsgrenzen und einen Pilotplan mit Abnahmekriterien.

  2. Pilot und Abnahme

    Du bekommst eine funktionierende Pipeline für die vereinbarten Anlagen, Dashboards und Alarmregeln, getestet mit echten oder aufgezeichneten Maschinendaten und abgenommen von einer benannten Person.

  3. Erweiterung und Betreuung

    Weitere Linien, Standorte und Signale werden gesondert mit Umfang und Reaktionszuständigkeiten vereinbart. Das begründet keine 24/7-Abdeckung und kein Verfügbarkeits-SLA.

Bring die Leute mit, denen Anlage und Netzwerk gehören

Wir brauchen die Anlagenliste, was du über Steuerungen und Protokolle weißt, bestehende Gateways oder SCADA, die betroffenen Netzwerkzonen, eine anlagenverantwortliche Person und einen IT- oder OT-Kontakt, der Zugriffe freigeben kann. Beispieldaten oder ein Test-Gateway verkürzen die Analyse deutlich. Verantwortung für Sicherheit und Maschinenrichtlinie bleibt beim Betreiber; dieser Auftrag zertifiziert weder Anlagen noch Netzwerke.

Was wir gebaut haben, und was nicht

Unsere Erfahrung mit Feldgeräten stammt aus der LoRaWAN-Arbeit im stadtweiten Smart-City-Aufbau der IKB in Innsbruck, mit Infrastruktur, Multi-Vendor-Geräten und gerätespezifischen Codecs. Einen veröffentlichten Fall aus Fabrik oder Werk haben wir noch nicht. Wir schreiben die Software oberhalb von Steuerung und Firmware und holen Spezialisten dazu, wenn ein Projekt SPS- oder Firmware-Arbeit braucht. Diese Grenze bekommst du schriftlich, bevor der Pilot startet.
// beweise

Angrenzende Arbeit mit Feldgeräten und Telemetrie

IKB dokumentiert Engineering im stadtweiten LoRaWAN-Aufbau in Innsbruck an der Seite des eigenen IKB-Teams, mit Erweiterung der Kubernetes-Infrastruktur, Multi-Vendor-Geräteintegration und gerätespezifischen Codecs, vollständig an das interne Team der IKB übergeben. Der Fall zeigt angrenzende Feldgeräte- und Telemetriearbeit, keinen Einsatz in einem Industriewerk.

IKB

Live
Komplett Plattformübergabe

Smart-City-IoT für Innsbruck: LoRaWAN-Infrastruktur erweitert und skaliert, Multi-Vendor-Geräte evaluiert und integriert, die …

Kubernetes LoRaWAN Docker
ENTERPRISE

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.

Fragen vor dem Start

Nein. Wir binden Steuerungen und Geräte über Gateways und bestehende Schnittstellen an und bauen alles oberhalb dieser Schicht. Braucht dein Projekt SPS- oder Firmware-Arbeit, sagen wir das in der Analyse und ziehen Spezialisten hinzu.
Nicht standardmäßig. Die Pipeline liest Daten. Ein schreibender Pfad ist ein eigener Umfang, abgestimmt mit der anlagenverantwortlichen Person, mit eigenen Tests und Freigabe.
Die, die zu Datenresidenz, Größenordnung und deinem Team passt. Die Optionen reichen von einem selbst betriebenen MQTT-Broker mit Zeitreihendatenbank bis zu einem verwalteten Cloud-IoT-Dienst. Wir vergleichen sie in der Analyse und empfehlen eine.
Oft ja, wenn es eine Schnittstelle bietet, die wir lesen dürfen. Aus einer bestehenden Schicht zu lesen ist meist sicherer, als neue Verbindungen direkt zu den Maschinen aufzubauen.
Noch keinen Fabrik-Fall. Unser veröffentlichter IoT-Nachweis ist der stadtweite Smart-City-Aufbau der IKB, in dem wir neben dem eigenen Team der IKB an Infrastruktur, Geräten und Codecs gearbeitet haben. Diesen Unterschied sagen wir offen, bevor du dich entscheidest.

Der passende nächste Schritt

Industrial-IoT-Projekt planen

Beschreib die Anlagen, die Protokolle, die du kennst, und das Signal, das du sehen musst. Ein grober Überblick reicht. Netzwerkpläne oder Zugangsdaten gehören nicht in die erste Nachricht.

Industrial-IoT-Projekt planen →