Architektur · Infrastruktur · Normen
Wie die Plattform gebaut ist
Kurzer Überblick über die Systemkomponenten, den Datenfluss vom Anhänger bis zum Kundenreport, das Datenmodell und die Normen-Compliance. Die Demo läuft lokal als Docker-Compose-Setup; die Produktionsarchitektur ergänzt Traefik, Authentik und optional K3s.
1. Systemübersicht — Datenfluss
2. Stack-Matrix
Begründungen pro Komponente (ADR-Light). Vollständige ADRs in DECISIONS.md.
| Schicht | Komponente | Version | Begründung | Alternative |
|---|---|---|---|---|
| Edge | Telegraf + Store-and-Forward | 1.33 | Industrie-Standard für Sensor-Agenten, robust bei Funkausfall | Custom Python auf Revolution Pi |
| Transport | EMQX | 5.8 | MQTT-Broker mit TLS + mTLS, horizontal skalierbar, Audit-Log | Mosquitto (einfacher, ohne Clustering) |
| Speicher — Zeitreihen | TimescaleDB | 2.17 / PG16 | PostgreSQL-nativ, Hypertables + Continuous Aggregates, SQL statt Fluxsprache | InfluxDB 2.x (reiner TSDB, zweite Datenbank nötig) |
| Speicher — Objekte | MinIO | 2024-10 | S3-kompatibler Rohdaten-Archiv, FZulG-Nachweise als WORM | AWS S3 / Ceph |
| Orchestrierung | Dagster | 1.9 | Asset-orientiert, materialisierte Dependencies, leichte Integration mit dbt | Prefect, Airflow |
| Transformation | dbt-core | 1.9 | Testbar, versioniert, dokumentiert — wichtig für FZulG-Nachweisführung | SQLMesh, reine SQL-Views |
| API | FastAPI | 0.115 | OpenAPI-Spec out-of-the-box, Pydantic-Validierung, async | Go + chi / Rust + axum |
| Frontend | Next.js App Router | 15 / React 19 | SSR + Server-Components, mobile-tauglich, schnelle Seitenwechsel | SvelteKit, Remix |
| Dashboards | Grafana | 11.3 | Standard für Technik-Dashboards, PostgreSQL-Datasource nativ | Superset, Metabase |
| Reverse Proxy | Traefik | 2.11 | Auto-TLS, Docker-Labels, geringe Config-Komplexität | Caddy, nginx-proxy |
| Observability | Prometheus + Loki + Grafana | — | Datenqualitätsmetriken als first-class Signale, nicht nur Infra-Metriken | Vector + ClickHouse |
3. Datenmodell
Stammdaten (blau) und Zeitreihen (grün) sind zwei Postgres-Schemas in derselben Datenbank — ein SQL-Abfrage-Layer, keine Cross-Datenbank-Joins. Events und Datenqualität-Flags leben im Analytics-Schema.
4. Normen & Compliance
| Referenz | Anwendungsbereich | Wie die Plattform das abbildet |
|---|---|---|
| DIN EN 12831 (Verfahren B) | Hydraulischer Abgleich nach Messung | Kampagne hinterlegt Vorher/Nachher-Spreizung; Event `hydraulic_balance` mit Kennzahlenvergleich. |
| VDI 2035 | Wasserqualität / Steinbildung | Leitfähigkeits- und Härte-Sensorwerte als optionaler Kanal im Schema. |
| GEG § 60c / § 71 | Hydraulischer Abgleich, JAZ-Nachweis | Reporting-Datenschicht liefert JAZ über Heizperiode aus TimescaleDB-CAGG. |
| VdZ-Fachregel | Durchführung hydraulischer Abgleich | Sensor-Kalibrier-Logs als Stammdaten, Techniker-Protokoll als Event. |
| GUM / DIN ISO 98-3 | Messunsicherheit | Pro Sensor `uncertainty_pct` erfasst, Fortpflanzung bei COP via symbolischer Berechnung. |
| DSGVO | Personenbezogene Gebäude-/Nutzerdaten | PII (Name, Adresse, Kontakt) in getrenntem Schema, Zugriff per Row-Level-Security; Löschkonzept auf Kampagnen-Ebene. |
| FZulG / BSFZ | FuE-Nachweisführung | Rohdaten als WORM-Objekt in MinIO, Dagster-Run-Logs als Audit-Trail, dbt-Modelle versioniert in Git. |
5. Messunsicherheit & Datenqualität
- Kalibrierung pro Sensor: Offset + Steigung je Sensor in
core.sensors; automatische Anwendung in der Ingest-Pipeline. - Messunsicherheit:
uncertainty_pctals GUM-konforme relative Unsicherheit; bei abgeleiteten Größen (COP, JAZ) Fortpflanzung nach Gauß'scher Quadratur. - Plausibilität: Regel-Engine prüft Wertebereich, Gradient (Spike-Erkennung) und Stale-Zustände. Cross-Channel-Check Energiebilanz
Q = ṁ·c_p·ΔTgegen Wärmemengenzähler. - Drift-Erkennung: Gleitender Vergleich Energiebilanz vs. thermischer Zähler; schleichende Abweichungen > 2 % werden als drift-Event annotiert.
- Ausfall-Strategien: Lücken < 15 min per Forward-Fill (markiert); größere Lücken bleiben als Qualitäts-Flag sichtbar und fließen nicht in Rollups ein.
6. KI-Roadmap
- Anomalie-Erkennung — IsolationForest-Baseline auf Residuen (gemessen vs. Modell), bereits in Demo als ML-Event sichtbar.
- Heizlast-Forecasting — gradient-boosted Trees (LightGBM) oder LSTM auf 24-h-Horizont, Inputs: Außentemperatur, Solarstrahlung, Belegungsmuster.
- Portfolio-Clustering — unsupervised Clustering von Gebäudetypen auf Basis von Heizkurve, spezifischer Verbrauch, Spreizungsverhalten → Empfehlungslogik für Sanierungspfade.
- Hybrid-Optimierung — MILP oder Reinforcement Learning: optimaler Umschaltpunkt Gas/WP unter Primärenergie-, CO₂- und Kostenzielfunktion.
7. Deployment-Optionen
- Single-Node (Demo)Docker Compose, eine VM, Traefik-TLS. Für Pilot-Kunden oder geschlossene Messkampagnen.
- Hybrid Edge + CloudAnhänger betreibt lokales TimescaleDB-Replikat (30 Tage Retention), MQTT-Bridge synchronisiert in die Cloud. Offline-tolerant.
- Multi-Tenant (K3s)Pro Kunde ein Schema, gemeinsame Infrastruktur. Authentik als SSO, Row-Level-Security auf Postgres-Ebene.