Causal Engine vs. Machine Learning: Wann welche Methode im Energie-Monitoring gewinnt

**TL;DR:** Machine Learning braucht meist 5.000–10.000 Trainingsbeispiele, um belastbare Muster zu finden. Eine Causal Engine arbeitet mit 15–50 handgeschriebenen Kausalketten und liefert bei kleinen Anlagen (BGA, PV, Nahwärme) oft schneller brauchbare Ergebnisse. ML schlägt Causal, sobald die Datenmengen groß und die Zusammenhänge unklar sind. Ein Vergleich am Beispiel einer 1 MW Biogasanlage.

---

## Das Problem: ML scheitert an kleinen Energie-Anlagen

Wer im Energie-Monitoring einen Standard-ML-Ansatz fährt — Random Forest, XGBoost, LSTM — stößt bei mittelständischen Anlagen an eine harte Grenze: **zu wenig Daten**.

Eine typische 1 MW Biogasanlage liefert bei 15-Minuten-Takt rund 35.000 Datenpunkte pro Jahr pro Messstelle. Klingt viel. Ist es aber nich

t, wenn man Anomalien erkennen will, die vielleicht 3–5 Mal im Jahr auftreten. Ein Trainingsdatensatz mit fünf positiven Beispielen reicht für kein Supervised-Learning-Modell.

Dazu kommt: BGA-Betreiber, kleine Stadtwerke und landwirtschaftliche PV+Biogas-Betriebe haben weder die Datenhistorie noch das Budget, um Modelle monatelang zu trainieren. Sie brauchen Monitoring, das **ab Tag eins** funktioniert.

### Was eine Causal Engine anders macht

Eine Causal Engine — Ansatz inspiriert vom LEAP-71-Pattern aus dem Raumfahrt-Engineering — dreht das Prinzip um: Statt Muster aus Daten zu lernen, werden Kausalketten als **explizite Regeln** kodiert. Beispiel:

> *Wenn Fermenter-Temperatur < 38 °C UND Gasproduktion fällt > 15 % in 24 h → wahrscheinliche Ursache: Versauerung. Gegenmaßnahme: Fütterung reduzieren, FOS/TAC prüfen.*

Das ist keine KI im engeren Sinn. Das ist formalisiertes Fachwissen. Aber genau das ist der Punkt.

---

## Wie eine Causal Engine im Energie-Monitoring aufgebaut ist

Bei Stromfee.AI nutzen wir 15 Kausalketten für BGA-Monitoring. Die Architektur folgt drei Schichten:

### 1. Signal-Layer (Messdaten)

Rohdaten aus Zählern (Janitza UMG, Gasflussmesser, PT100-Sensoren), typischerweise via Modbus TCP oder MQTT. Aktuell werden u. a. folgende Signale erfasst:

- Gasproduktion (Nm³/h)

- Fermenter-Temperatur (°C)

- BHKW-Wirkleistung (kW)

- Netzbezug/-einspeisung (kWh)

- FOS/TAC (falls Online-Messung)

- pH-Wert

- Rührwerk-Stromaufnahme

### 2. Rule-Layer (Kausalketten)

Jede Regel hat drei Teile: **Bedingung**, **Hypothese**, **Handlungsempfehlung**. Die 15 Regeln decken u. a. ab:

- Versauerung des Fermenters

- Schaumbildung (Rührwerk-Strom untypisch hoch)

- Gasspeicher-Überfüllung

- BHKW-Wirkungsgrad-Drift

- Einspeisemanagement-Eingriff nach §14a EnWG

- Eigenverbrauchs-Anomalien

### 3. Action-Layer (Alerting & Logging)

Treffer werden priorisiert, an den Betreiber gepusht (E-Mail, SMS, Dashboard) und in ClickHouse geloggt. Über Zeit entsteht ein Kausalitäts-Audit-Trail — wertvoll für Versicherungsfälle und Betriebsgenehmigungen.

---

## Der direkte Vergleich: 1 MW BGA in Norddeutschland

Ein 1 MW BGA-Betrieb in Norddeutschland war 2024 unser Testfall. Wir haben parallel zwei Ansätze laufen lassen: ein ML-Modell (Isolation Forest für Anomalieerkennung) und die Causal Engine mit 15 Regeln.

### Ergebnisse nach 6 Monaten

| Kriterium | Machine Learning (Isolation Forest) | Causal Engine (15 Regeln) |

|---|---|---|

| Zeit bis produktiv | ~3 Monate (Datensammlung + Training) | 2 Wochen (Regel-Konfiguration) |

| Anzahl erkannte Vorfälle | 11 | 9 |

| Davon echte Positives | 4 (≈36 %) | 7 (≈78 %) |

| False Positives | 7 | 2 |

| Erklärbarkeit | gering (Black Box) | hoch (Regel nachlesbar) |

| Wartungsaufwand | Re-Training nötig | Regel anpassen |

*Hinweis: Die Zahlen stammen aus einem einzelnen Anlagenkontext. Eine Hit-Rate von 78 % wäre bei breiter Anwendung zu prüfen — in anderen Anlagen kann das deutlich schwanken.*

Die Causal Engine war also nicht "besser" in absoluten Zahlen, aber **schneller produktiv** und **erklärbar**. Der Betreiber konnte jeden Alarm nachvollziehen. Das ist kein akademisches Detail — das ist der Unterschied zwischen "Alert wird ernst genommen" und "Alert wird ignoriert".

---

## Wann Machine Learning klar überlegen ist

Ich will hier nicht den Eindruck erwecken, Causal Engines seien die bessere Lösung. Sie sind es in bestimmten Szenarien. ML gewinnt, sobald:

### Skalierung hoch ist

Wer 500 PV-Anlagen überwacht, kann nicht 500 Mal manuell Regeln pflegen. Hier skaliert ML besser — ein Modell lernt auf dem Schwarm und generalisiert.

### Zusammenhänge unbekannt sind

Bei der [electricity_price_forecast Pipeline von Stromfee](https://stromfee.ai) nutzen wir Prophet ML mit 96 Preissignalen. Warum? Weil die Zusammenhänge zwischen Wetter, Gaspreis, Lastprognose und Day-Ahead-Preis so viele nichtlineare Interaktionen haben, dass kein Mensch 96 Regeln sauber schreiben kann. Hier lernt ML Muster, die handgeschriebene Regeln nie erfassen würden.

### Datenmengen massiv sind

In der ClickHouse-Datenbank liegen [4,4 Millionen Redispatch-Maßnahmen seit 2013](https://stromfee.ai). Bei dieser Größenordnung wäre ein Regelsystem absurd — hier finden Gradient-Boosting-Modelle Muster, die in Einzelfällen unsichtbar sind.

### Fazit der Abgrenzung

- **Causal Engine**: Kleine Anlage, klare Physik, wenig Daten, Erklärbarkeit kritisch.

- **Machine Learning**: Viele Anlagen, unklare Zusammenhänge, große Datenhistorie, Generalisierung wichtig.

Die meisten ernsthaften Monitoring-Systeme sollten **beide** kombinieren.

---

## Hybrid-Architektur: Causal + ML

In der Praxis ergibt ein hybrider Aufbau am meisten Sinn. Die Causal Engine fängt die kritischen, erklärbaren Fälle ab. Das ML-Layer läuft parallel und flaggt Anomalien, für die keine Regel existiert. Menschen schauen sich diese Anomalien an und schreiben ggf. eine neue Regel.

So wächst die Regelbasis organisch — von 15 auf 30 auf 50 Regeln — während das ML-Layer das „noch nicht verstandene" abdeckt. Dieses Muster kommt aus dem Raumfahrt-Kontext (LEAP-71), wo man weder rein deterministisch noch rein datengetrieben arbeiten kann.

### Beispiel aus der BGA-Praxis

Die Causal Engine erkennt Versauerung nach Regel. Das ML-Layer flaggt aber auch eine ungewöhnliche Korrelation zwischen Rührwerk-Strom und BHKW-Wirkungsgrad, für die keine Regel existiert. Der Betreiber prüft — es stellt sich heraus, dass verschlissene Rührwerkslager den Fermenter-Prozess beeinflussen. Neue Regel wird geschrieben. Das System wird schlauer.

---

## Regulatorische Relevanz: Erklärbarkeit wird Pflicht

Ein Punkt, der oft übersehen wird: Die BNetzA und Netzbetreiber fordern bei §14a-EnWG-Eingriffen und Redispatch-2.0-Meldungen zunehmend **nachvollziehbare Entscheidungswege**. Wenn ein Monitoring-System einen Einspeisestopp auslöst, muss der Betreiber begründen können, warum.

Eine Black-Box-ML-Entscheidung ist hier problematisch. Eine Causal-Regel ("Bedingung X war erfüllt, deshalb Aktion Y") dagegen ist dokumentierbar und auditfähig. Bei der [EU AI Act](https://stromfee.me)-Umsetzung ab 2026 wird dieser Punkt für Energie-Anwendungen relevanter werden — Stichwort "Hochrisiko-KI" in kritischer Infrastruktur.

---

## Praktische Umsetzung: Wie startet man?

Wer eine Causal Engine für sein Energie-Monitoring aufbauen will, sollte pragmatisch starten:

1. **5 Regeln schreiben.** Nicht 50. Die häufigsten Ausfallursachen aus den letzten 2 Jahren identifizieren und als Regel formalisieren.

2. **Signal-Layer sauber aufbauen.** MQTT oder Modbus TCP auf ClickHouse, Grafana, InfluxDB — egal, Hauptsache konsistent.

3. **Alerting mit Mensch im Loop.** Jeden Alarm 4 Wochen lang manuell prüfen. False Positives führen zu Regel-Anpassung.

4. **Regel-Basis organisch wachsen lassen.** Pro Monat 1–2 neue Regeln, basierend auf echten Vorfällen.

5. **ML erst später draufsetzen.** Wenn die Causal-Basis stabil läuft und genug Daten da sind.

Wer hier einen Einstieg sucht, findet in der [Stromfee Academy](https://stromfee.ai) Simulatoren und Fallstudien, u. a. das BESS-PV-Game und einen Arbitrage-Simulator.

---

## Zusammenfassung

Machine Learning ist ein mächtiges Werkzeug — aber kein Universalschlüssel. In kleinen, physikalisch gut verstandenen Energie-Anlagen wie Biogas, Nahwärme oder Hof-PV gewinnt die Causal Engine durch **Geschwindigkeit, Erklärbarkeit und niedrigen Datenbedarf**. Bei großen Datenmengen und unklaren Zusammenhängen — Preisprognose, Lastprognose, Redispatch-Analyse — schlägt ML zurück.

Die beste Architektur kombiniert beide. Und fängt klein an.

**Call-to-Action:** Wenn Sie überlegen, ob eine Causal Engine für Ihren BGA- oder PV-Betrieb sinnvoll ist, [sprechen Sie uns an](https://stromfee.ai/contact) — wir prüfen gerne unverbindlich, welche 5 Regeln bei Ihrem Anlagentyp den größten Hebel haben.

---

## FAQ

**1. Was ist eine Causal Engine im Energie-Monitoring?**

Ein regelbasiertes System, das Kausalketten (Ursache → Wirkung → Handlungsempfehlung) explizit formalisiert. Es ersetzt oder ergänzt Machine Learning, besonders bei kleinen Datenmengen.

**2. Wie viele Regeln braucht eine Causal Engine?**

Für eine 1 MW BGA reichen erfahrungsgemäß 15–20 Regeln für die häufigsten Ausfallursachen. Größere Systeme können 50+ Regeln umfassen.

**3. Kann eine Causal Engine Machine Learning komplett ersetzen?**

Nein. Bei großen Datenmengen und unklaren Zusammenhängen (z. B. Day-Ahead-Preisprognose) ist ML klar überlegen. Causal Engines sind für kleine, physikalisch gut verstandene Systeme stark.

**4. Was ist der Unterschied zu klassischen SPS-Alarmen?**

Klassische Alarme reagieren auf einzelne Schwellwerte. Eine Causal Engine verknüpft mehrere Signale über Zeit und liefert eine wahrscheinliche Ursache plus Handlungsempfehlung.

**5. Wie lange dauert die Implementierung?**

Der Signal-Layer (Datenanbindung via Modbus/MQTT) braucht 1–2 Wochen, die ersten 5 Regeln nochmal 1–2 Wochen. Nach 4–6 Wochen läuft ein erstes produktives System.

**6. Wie relevant ist das für §14a EnWG und Redispatch 2.0?**

Sehr. Wer Einspeisemanagement oder Lastverschiebung automatisch steuert, muss Entscheidungen nachvollziehbar dokumentieren. Regelbasierte Sys

[gekürzt]