Von DIN-Normen zu API-Endpunkten: HLK-Berechnungen für das Web kodieren

Das Problem mit DIN-Normen

DIN EN 12831 ist die europäische Norm zur Berechnung der Norm-Heizlast von Gebäuden. Es sind 120 Seiten Tabellen, Formeln, Korrekturfaktoren und Entscheidungsbäume — veröffentlicht als PDF, das man lesen, verstehen und per Hand (oder mit Excel) anwenden soll.

Die Norm ist präzise. Der Workflow drumherum ist es nicht.

Als ich Mepbau zu bauen begann, war die Kernherausforderung nicht das Erstellen einer Web-App — es war das Kodieren einer 120-seitigen Ingenieursnorm in Software, die Ergebnisse liefert, denen Ingenieure vertrauen.

Dieser Beitrag beschreibt, wie ich das für DIN EN 12831 gemacht habe, welche Entscheidungen ich getroffen habe, in welche Fallen ich getappt bin und welche Muster sich für die Kodierung weiterer Normen (VDI 2078, DIN 1946-6 und mehr) herauskristallisiert haben.

Die Norm in 60 Sekunden

DIN EN 12831 berechnet die Norm-Heizlast (Φ_HL) für jeden Raum eines Gebäudes — die maximale Heizleistung, die nötig ist, um die Auslegungsinnentemperatur unter den kältesten erwarteten Außenbedingungen aufrechtzuerhalten.

Die Kernformel ist trügerisch einfach:

Φ_HL = Φ_T + Φ_V + Φ_RH

Dabei ist:

• Φ_T = Transmissionswärmeverlust (Wärme, die durch Wände, Fenster, Dach, Boden entweicht)
• Φ_V = Lüftungswärmeverlust (Wärme, die durch Luftaustausch verloren geht)
• Φ_RH = Wiederaufheizleistung (Zusätzliche Leistung, um einen kalten Raum zurück auf Temperatur zu bringen)

Jede dieser Komponenten entfaltet sich in einen Baum aus Teilberechnungen, Korrekturfaktoren und Tabellennachschlägen. Darin liegt die Komplexität.

Schritt 1: Das Domänenmodell

Bevor ich irgendeine Berechnungslogik schrieb, definierte ich das Datenmodell. Die Norm arbeitet mit einer Hierarchie: Gebäude → Zonen → Räume → Hüllflächenkomponenten.

Jeder Raum hat:

• Grundgeometrie (Grundfläche, Höhe, Volumen)
• Eine Auslegungsinnentemperatur (typischerweise 20°C für Wohnräume, 24°C für Bäder)
• Eine Liste von Hüllflächenkomponenten — jede Fläche, die den Raum von außen oder von angrenzenden unbeheizten Räumen trennt

Jede Hüllflächenkomponente hat:

• Einen Typ (Außenwand, Fenster, Tür, Dach, Bodenplatte gegen Erdreich, Decke zu unbeheiztem Raum, Innenwand zu unbeheiztem Raum)
• Eine Fläche in m²
• Einen U-Wert in W/(m²·K) — den Wärmedurchgangskoeffizienten
• Korrekturfaktoren für Exposition, Wärmebrücken und Nachbartemperaturen

Zusätzlich zu den Raumdaten braucht man Klimadaten — die Norm-Außentemperatur für den Gebäudestandort (z.B. -13°C für Berlin, -16°C für München) und die mittlere Jahresaußentemperatur.

Jedes Feld bildet direkt eine Variable der Norm ab. Dieses Modell richtig zu bekommen, ist der wichtigste Schritt — alles andere folgt daraus.

Schritt 2: Der Berechnungskern

Mit dem Domänenmodell folgen die Berechnungen Abschnitt für Abschnitt der Norm:

Transmissionswärmeverlust (Φ_T)

Für jede Hüllflächenkomponente den Wärmedurchgangskoeffizienten (H_T) berechnen, indem man Fläche mit U-Wert und Korrekturfaktoren multipliziert. Dann über alle Komponenten summieren und mit der Temperaturdifferenz zwischen innen und außen multiplizieren.

Verschiedene Komponententypen werden unterschiedlich behandelt:

• Außenflächen (Wände, Fenster, Dach): direkte Multiplikation
• Flächen zu unbeheizten Räumen (Boden über Garage, Wand zum Treppenhaus): Temperatur-Korrekturfaktor anwenden, der die Zwischentemperatur des unbeheizten Raums berücksichtigt
• Bodenplatte gegen Erdreich: Sonderformel mit Jahrestemperaturschwankungs-Korrekturen und Grundwasserkorrekturen gemäß Anhang A der Norm

Lüftungswärmeverlust (Φ_V)

Den Auslegungs-Luftvolumenstrom berechnen — den höheren Wert aus dem Mindestlüftungsbedarf (aus DIN 1946-6 oder einem vereinfachten Mindestluftwechsel) und dem Infiltrations-Luftvolumenstrom durch die Gebäudehülle.

Die Infiltration hängt von der Luftdichtheit des Gebäudes ab (gemessen als n50-Wert aus dem Blower-Door-Test), einem Windabschirmungskoeffizienten und einem Höhenkorrekturfaktor. Wenn keine Blower-Door-Messung vorliegt, schreibt die Norm Standardwerte vor.

Den Auslegungs-Luftvolumenstrom mit der volumetrischen Wärmekapazität der Luft (0,34 Wh/m³·K) und der Temperaturdifferenz multiplizieren.

Wiederaufheizleistung (Φ_RH)

Eine optionale Komponente für Gebäude mit unterbrochenem Heizbetrieb (z.B. Nachtabsenkung). Basiert auf der Grundfläche des Raums und einem Wiederaufheizfaktor.

Gesamte Heizlast

Alle drei Komponenten summieren. Das ist die Norm-Heizlast für einen Raum. Für jeden Raum wiederholen, dann für das gesamte Gebäude summieren.

Schritt 3: Die API-Schicht

Mit dem funktionierenden Berechnungskern verpackte ich ihn in eine Web-API. Das Frontend sendet ein JSON-Paket, das das Gebäude beschreibt — Standort, Räume, Hüllflächenkomponenten mit ihren Eigenschaften. Das Backend validiert die Eingabe (lehnt negative Flächen, unvernünftige U-Werte, fehlende Pflichtfelder ab), führt die Berechnung durch und gibt die Ergebnisse zurück.

Die API-Antwort enthält nicht nur die finale Heizlastzahl, sondern jeden Zwischenwert: den Transmissions-Wärmedurchgangskoeffizienten für jede Komponente, den Lüftungs-Volumenstrom, die Temperaturdifferenz, die einzelnen Verlustkomponenten. Diese Transparenz ist entscheidend — so überprüfen Ingenieure, ob die Software die Norm korrekt anwendet.

Eingabevalidierung ist bei Ingenieurberechnungen besonders wichtig. Ein vertippter U-Wert von 2,8 statt 0,28 würde ein Ergebnis erzeugen, das um eine Größenordnung daneben liegt. Die API lehnt Werte außerhalb physikalisch vernünftiger Bereiche ab, bevor sie den Berechnungskern erreichen.

Schritt 4: Validierung gegen bekannte Ergebnisse

Dies ist der kritischste Schritt. Ingenieure vertrauen nur Software, die Ergebnisse liefert, die sie überprüfen können. Meine Validierungsstrategie hat drei Ebenen:

Referenzbeispiele aus der Norm

DIN EN 12831 enthält durchgerechnete Beispiele in ihren Anhängen. Diese sind der Goldstandard. Ich habe Testfälle gebaut, die diese Beispiele exakt reproduzieren und verifizieren, dass mein Berechnungskern die erwarteten Ergebnisse liefert.

Kreuzvalidierung mit bestehender Software

Ich habe Parallelberechnungen in Solar Computer und Hottgenroth für dieselben Gebäude durchgeführt und die Ergebnisse verglichen. Abweichungen unter 3% sind akzeptabel. Abweichungen über 5% müssen untersucht werden.

Sensitivitätsanalyse

Für jeden Eingabeparameter habe ich ihn um ±10% variiert und geprüft, ob sich das Ergebnis in die erwartete Richtung und im erwarteten Ausmaß bewegt.

Gelernte Lektionen: Normen in Software kodieren

Nach der Implementierung von sieben DIN/VDI-Normen kristallisierten sich klare Muster heraus:

1. Tabellen werden zu strukturierten Nachschlägen

Normen stecken voller Nachschlagetabellen — „Norm-Außentemperatur nach Stadt", „Abschirmkoeffizient nach Expositionsklasse und Gebäudehöhe", „Mindestluftwechselrate nach Raumtyp." Jede davon wird zu einem strukturierten Daten-Lookup in der Software. Allein für Klimadaten habe ich 180+ deutsche Städte aus Tabelle NA.1 der DIN EN 12831 kodiert.

2. Entscheidungsbäume werden zu Verzweigungslogik

„Den Korrekturfaktor basierend auf Gebäudetyp und Exposition auswählen" — die Norm beschreibt das als Tabelle mit Zeilen und Spalten. In Software wird daraus strukturierte Verzweigungslogik, die dieselben Eingaben nimmt und dieselbe Ausgabe liefert.

3. Genauigkeit zählt mehr als Geschwindigkeit

Eine Heizlastberechnung läuft in Millisekunden. Niemanden interessiert, ob es 5ms oder 50ms dauert. Aber wenn das Ergebnis um 200W daneben liegt bei einem Raum, der einen 2000W-Heizkörper braucht, wird der Gebäudebesitzer das im Januar spüren.

Ich verwende durchgehend hochpräzise Arithmetik und runde erst in der finalen Ausgabe. Zwischenergebnisse werden nie gerundet — Rundungsfehler kumulieren sich über hunderte Räume.

4. Zeig deine Arbeit

Die größte Feature-Anfrage der ersten Nutzer war nicht „schneller machen" oder „mehr Normen." Es war „Zeig mir, wie du auf diese Zahl kommst."

Jede API-Antwort enthält die Zwischenwerte — Transmissionskoeffizienten, Luftvolumenströme, Temperaturdifferenzen. Ingenieure vertrauen keinen Black Boxes. Sie vertrauen transparenten Berechnungen, die sie Schritt für Schritt nachvollziehen können.

5. Normen verweisen auf andere Normen

DIN EN 12831 sagt, Lüftungsraten „nach DIN 1946-6" zu berechnen. DIN 1946-6 sagt, Gebäudehüllen-Luftdichtheitswerte „nach DIN 4108-7" zu verwenden. Man kann keine Norm isoliert implementieren — der Abhängigkeitsgraph ist tief.

Was kommt als Nächstes

DIN EN 12831 war das Fundament. Die gleichen Muster — Domänenmodell, Berechnungskern, API-Schicht, Referenzvalidierung — gelten für jede Norm:

• VDI 2078 (Kühllast): komplexer, weil stündliche Solarstrahlungsberechnungen erforderlich sind
• DIN 1946-6 (Lüftung): einfachere Mathematik, aber mehr Entscheidungsbäume für die Systemauswahl
• DIN 1988-300 (Sanitär): Rohrdimensionierung mit iterativen Druckverlustberechnungen
• VDI 4645 (Wärmepumpen): kombiniert Heizlast mit Erdreich-/Luftquellendaten für die Dimensionierung

Jede Norm hat ihre eigenen Besonderheiten, aber die Architektur ist dieselbe: Domäne kodieren, Mathematik implementieren, gegen Referenzen validieren, über API bereitstellen und Arbeit zeigen.

Die deutsche TGA-Branche ist bereit für cloudnative Tools. Die Normen sind klar definiert, die Berechnungen sind deterministisch, und die bestehende Desktop-Software hat seit Jahren nicht innoviert. Der schwierige Teil ist nicht die Technologie — es ist das Vertrauen der Ingenieure zu gewinnen.

Bauen Sie Berechnungskerne für Ingenieurnormen? Schreiben Sie mir an hello@laborsam.com.