OT trifft IT: Wie Sie Maschinendaten sauber ins Energiemanagement bekommen

Wer in den letzten Jahren Energiemanagement-Projekte begleitet hat, kennt das Muster: Die Geschäftsführung gibt grünes Licht, die Energiebeauftragte:r ist motiviert, das Lastenheft ist klar — und dann beginnt das eigentliche Projekt erst: die Datenintegration. OT (Operational Technology, also die Werks-Steuerung) trifft IT (die Büro-Welt) — und beide haben unterschiedliche Sprachen, Sicherheitsverständnisse und Prioritäten.

Wir haben in zehn Jahren Dutzende Datenintegrations-Projekte begleitet. Hier ist, was wir gelernt haben — und was Sie wissen sollten, bevor Sie loslegen.

Warum OT und IT sich oft nicht verstehen

OT-Welt: SPSen, SCADA, Feldbusse, Sensoren. Stabilität ist alles, Updates sind selten, Sicherheit bedeutet vor allem Ausfallsicherheit. Ein Kompressor, der nicht läuft, kostet Geld pro Minute. Patches werden geplant, oft monatelang.

IT-Welt: Server, Datenbanken, Cloud, Webdienste. Updates sind ständig, Sicherheit bedeutet vor allem Daten- und Zugriffsschutz. Eine offene SCADA-Schnittstelle ist für die IT ein Albtraum.

Beide haben Recht. Aber Energiemanagement braucht Daten aus beiden Welten. Wer das Projekt naiv angeht, scheitert an der Brücke.

Die fünf Datenquellen, die Sie typischerweise anzapfen

In einem typischen Industriestandort kommen die Energiedaten aus diesen Quellen:

Quelle 1: Direkter Sensor-Anschluss (Modbus, M-Bus)

Stromzähler, Wärmemengenzähler, Gaszähler. Klassische Schnittstellen wie Modbus TCP/RTU oder M-Bus, oft direkt an der Energie-Hauptverteilung. Vorteil: präzise, hohe Frequenz möglich. Nachteil: muss verkabelt oder per Gateway angebunden werden.

Quelle 2: SCADA-Mittelschicht (OPC UA, MQTT)

Wenn Sie bereits ein SCADA-System (Wonderware, WinCC, iFix) haben, sammeln dort die Maschinendaten zusammen. Die Energiedaten lassen sich oft über OPC UA herausziehen — eine moderne, sichere Schnittstelle. Vorteil: Daten sind schon strukturiert. Nachteil: Sie sind abhängig von der SCADA-Pflege.

Quelle 3: ERP/MES (SAP, Oracle, MS Dynamics)

Produktionsdaten kommen aus dem ERP oder dem MES. Stückzahlen, Auftragsdaten, Schichtmodelle, Materialeinsatz. Für multivariate EnPIs unverzichtbar — ohne diese Daten ist „kWh pro Tonne Stahl” nur Statistik. Vorteil: gepflegte Daten. Nachteil: oft hohe interne Hürden für Zugriff.

Quelle 4: Energieversorger-Lastgangdaten

Vom Energieversorger als CSV oder über API. Standardlastprofile (SLP), 15-Minuten-Werte, monatliche Abrechnungs-Daten. Vorteil: amtlich genau. Nachteil: oft mit Verzögerung verfügbar, nur Aggregate.

Quelle 5: Wetterdaten

Wer multivariate EnPIs mit Außentemperatur-Bezug rechnet, braucht Wetterdaten. Typisch über DWD-Schnittstelle oder kommerzielle Wetterdienste. Vorteil: einfach. Nachteil: regionale Genauigkeit prüfen.

Die drei Architektur-Muster, die wir in der Praxis sehen

Muster 1: Sensor-direkt-in-EnMS

Sensoren werden direkt an die EnMS-Software angebunden, ohne SCADA-Zwischenschicht. Funktioniert für kleine Standorte oder Pilotbereiche. Vorteil: einfach, schnell. Nachteil: Wenn Sie viele Sensoren haben, wird das schnell unübersichtlich.

Wann passt das? Kleinere Werke (unter 50 Sensoren), Pilotbereiche, Werke ohne etabliertes SCADA.

Muster 2: SCADA-als-Mittelschicht

Die EnMS-Software liest aus dem SCADA. Das SCADA macht die Sensorintegration, die EnMS-Software bekommt strukturierte Daten. Vorteil: Trennung der Verantwortlichkeiten, IT-Sicherheit gewahrt. Nachteil: SCADA muss gepflegt werden, jeder neue Datenpunkt erfordert SCADA-Konfiguration.

Wann passt das? Mittlere bis große Werke mit etabliertem SCADA, klassische OT/IT-Trennung im Unternehmen.

Muster 3: Daten-Plattform (DataLake / TimeSeries-DB)

Alle Daten gehen in eine zentrale Plattform (z.B. InfluxDB, TimescaleDB, Azure IoT). EnMS-Software liest dort, andere Anwendungen auch. Vorteil: maximale Flexibilität, keine Insellösung. Nachteil: hoher Architektur-Aufwand, IT-Projekt.

Wann passt das? Konzern-Standorte mit Digital-Twin-Strategie, mehreren Anwendungen auf gleichen Daten.

Was wir bei OT-IT-Projekten häufig scheitern sehen

Drei Muster, die regelmäßig Projekte ausbremsen:

Scheitern 1: Die IT-Sicherheit wird zu spät einbezogen

Klassisch: Energiebeauftragte:r und Werksleitung haben das Projekt fertig geplant, ein Pilot läuft — und dann sagt die IT „Halt, das geht so nicht.” Firewall-Regeln müssen angepasst werden, Authentifizierung ist nicht geklärt, kein VLAN dafür da.

Was hilft: IT von Tag 1 dabei. Wir machen das in unseren Projekten so: Erste Session mit Energiebeauftragte:r, Werksleitung und IT-Vertretung. Selbst wenn die IT nur zuhört.

Scheitern 2: Daten kommen, aber niemand pflegt sie

Sensor-Anbindung läuft, Daten fließen — und nach 6 Monaten merkt jemand, dass ein Sensor falsch kalibriert ist, ein anderer ausgefallen ist, ein dritter falsch zugeordnet wurde. Niemand pflegt die „Stamm­daten” der Datenquellen.

Was hilft: Vor dem Projekt klären: Wer ist für die Pflege der Sensoren verantwortlich? Wer kalibriert wann? Wer reagiert auf Ausfälle? In der Regel ist das die Instandhaltung — aber nur, wenn das vereinbart ist.

Scheitern 3: Die ERP-Anbindung blockiert

SAP-Daten sind oft im Konzern „heilig”. Selbst Lesezugriff auf wenige Tabellen kann monatelange Genehmigungsprozesse auslösen. Energie-Projekte werden hier oft ausgebremst.

Was hilft: Frühe Klärung mit dem SAP-Team, welche Daten Sie brauchen, in welcher Form. Oft reicht ein nächtlicher Export einer kleinen View — keine Live-Anbindung. Das ist für SAP-Verantwortliche meist akzeptabel.

Die Sicherheits-Frage, die jede IT stellt

„Wenn ihr Daten aus unserer Steuerungsebene zieht, was passiert wenn die Verbindung kompromittiert wird?”

Die Antwort, die Sie geben sollten:

1. Lesender Zugriff, niemals schreibend. Energie-Daten werden gelesen — keine Steuerbefehle gehen zurück ins OT.
2. Trennung über Firewall mit definierten Ports. Kein Direktzugriff von außen.
3. Authentifizierung über VPN/Zertifikate. Wenn die EnMS in der Cloud läuft, muss der Zugriff über eine zertifikat-basierte Verbindung erfolgen.
4. Audit-Trail auf beiden Seiten. Sowohl in OT als auch in EnMS wird protokolliert, was gelesen wurde.
5. OT-Read-Only-User mit minimalen Rechten. Der EnMS-Service-Account darf genau das, was er muss — und nichts mehr.

Mit dieser Antwort kommen Sie durch jede IT-Sicherheits-Sitzung. Wir haben das schon mit ITSiG-pflichtigen Stadtwerken durchgespielt.

Ein realistischer Zeitplan

Wenn Sie OT-IT-Integration neu aufsetzen, hier eine Erfahrungswerte-Zeitachse:

Woche	Aufgabe
1–2	Bestandsaufnahme: welche Datenquellen, welche Schnittstellen, welche IT-Sicherheits-Anforderungen
3–4	Architektur-Entscheidung (Muster 1, 2 oder 3), Abstimmung mit IT
5–6	Pilot: 5–10 Datenpunkte aus einem Bereich anbinden, Datenfluss validieren
7–10	Roll-out auf weitere Bereiche, Sensor-Pflege etablieren
11–12	Stabilisierung, Monitoring, Übergang in Regelbetrieb

Drei Monate für einen mittelgroßen Standort. Schneller geht, dauert aber meist länger. Wer schneller verspricht, hat noch keine OT-Realität erlebt.

Was wir konkret tun

ecorize unterstützt alle gängigen OT-Protokolle (Modbus TCP/RTU, OPC UA, MQTT, M-Bus, Ethernet/IP) und die wichtigsten ERP/MES-Systeme (SAP S/4HANA, Oracle, MS Dynamics). Wir arbeiten häufig im Muster 2 (SCADA-Mittelschicht), weil das die saubere OT/IT-Trennung beibehält.

Bei größeren Konzern-Projekten gehen wir Muster 3 mit (Daten-Plattform). Wir konnektieren uns dort als „Konsument” auf eine bestehende TimeSeries-DB, ohne ein paralleles System zu bauen.

Im Detail: Produkt-Seite Forecasting & EnPI zeigt, wie wir mit den integrierten Daten arbeiten. IMS-Integration zeigt die technischen Schnittstellen im Überblick.

Was Sie jetzt tun können

Wenn Sie ein OT/IT-Integrations-Projekt vorbereiten, hilft eine ehrliche IT-Architektur-Session. Wir bieten 45-Minuten-Sessions mit unserem technischen Lead an — ohne Sales-Begleitung, wenn Sie wollen. Termin anfragen über info@ecorize.com.

Oder erst einmal sortieren, wo Sie stehen: Reifegrad-Check. Eine der Fragen zielt explizit auf Ihre Datenlage.