Das Softwareproblem der HLK-Branche — Und warum Ingenieure ihre eigenen Tools bauen

Der Zustand der TGA-Software im Jahr 2025

Lassen Sie mich einen typischen Tag eines HLK-Ingenieurs in Deutschland beschreiben.

Sie kommen ins Büro. Sie öffnen Revit, um am Lüftungslayout für ein Krankenhausprojekt zu arbeiten. Sie müssen überprüfen, ob Ihre Kanaldimensionierung die Auslegungs-Luftvolumenströme aus dem Lüftungskonzept erfüllt. Das Konzept wurde in einer anderen Software berechnet — Solar Computer — also öffnen Sie die auch. Die Klimadaten kommen aus einer DIN-Norm, die Sie von einer PDF auf Ihrem Desktop referenzieren. Der Architekt hat gerade den Grundriss geändert, also müssen Sie die Raummaße aktualisieren. Sie kopieren sie aus Revit, fügen sie in Solar Computer ein, führen die Berechnung erneut durch und prüfen manuell, ob die Kanalgrößen in Ihrem Revit-Modell noch passen.

Dann bekommen Sie eine E-Mail: Der Energieberater braucht die Heizlastberechnung im Hottgenroth-Format, aber Ihre Berechnung wurde in Solar Computer gemacht, und die beiden Tools teilen keine Daten. Also geben Sie die Gebäudeparameter in Hottgenroth erneut ein — dieselben U-Werte, dieselben Raummaße, dieselben Klimadaten — zum dritten Mal heute.

Es ist 11 Uhr. Sie haben noch keine eigentliche Ingenieurarbeit geleistet.

Das ist keine Karikatur. Das ist der tägliche Alltag für tausende TGA-Ingenieure in Deutschland, Österreich und der Schweiz. Und es ist ein Problem, das Software vor einem Jahrzehnt hätte lösen sollen.

Warum die bestehenden Tools nicht ausreichen

Die dominanten TGA-Berechnungstools im DACH-Markt haben sich seit den frühen 2000ern nicht grundlegend verändert:

Solar Computer

Marktführer für Heiz-/Kühllastberechnungen. Die Oberfläche sieht aus, als wäre sie für Windows XP gestaltet — weil sie es wurde. Kompetenter Berechnungskern, aber strikt Desktop-gebunden, Einzelplatz, keine API, keine BIM-Integration jenseits eines einfachen IFC-Imports.

Hottgenroth

Stark in der Energieberatung und KfW-Förderberechnungen. Ähnliches Baujahr. Bekannt dafür, genau die Berichtsformate zu erzeugen, die Baubehörden erwarten — weshalb Berater trotz der UX dabei bleiben.

Trimble Nova (ehemals Plancal)

In Revit für TGA-Berechnungen integriert. Das modernste Tool im Markt, aber teuer (5.000+ €/Jahr) und eng an das Trimble-Ökosystem gekoppelt.

Die gemeinsamen Probleme

Das Ergebnis: Maschinenbauingenieure verbringen mehr Zeit mit dem Kampf gegen Software als mit Ingenieurarbeit.

Das Excel-Problem

Wenn die lizenzierte Software zu teuer oder zu starr ist, greifen Ingenieure zu Excel zurück. Und Excel ist trotz seiner Flexibilität eine schreckliche Plattform für Ingenieurberechnungen:

• Keine Versionskontrolle. Welche Version der Tabelle hat die aktuellen Klimadaten? Die aus der E-Mail, die auf dem Server oder die auf dem Desktop?
• Keine Validierung. Ein vertippter U-Wert (0,28 vs. 2,8) pflanzt sich stillschweigend durch die gesamte Berechnung fort.
• Keine Wiederverwendbarkeit. Jedes Büro hat seine eigene Excel-Vorlage für DIN EN 12831, jede mit leicht unterschiedlichen Annahmen und Bugs.
• Keine Zusammenarbeit. Zwei Ingenieure können nicht gleichzeitig an derselben Berechnung arbeiten.
• Keine Nachvollziehbarkeit. Viel Glück beim Erklären gegenüber einem Baubehörden-Prüfer, welche Zellen in Ihrer 47-Reiter-Arbeitsmappe welchen Klauseln der Norm entsprechen.

Warum jetzt? Was hat sich geändert?

Drei Trends konvergieren und machen dies zum richtigen Zeitpunkt für cloudnative TGA-Tools:

1. Das BIM-Mandat

Deutschlands öffentlicher Sektor verlangt zunehmend BIM für Bauprojekte. BIM bedeutet digitale Gebäudemodelle, standardisierten Datenaustausch und — entscheidend — die Erwartung, dass Planungsdaten ohne manuelle Neueingabe zwischen Tools fließen.

Wenn die Branche digitale Workflows vorschreibt, müssen die Berechnungstools auch digital-nativ sein.

2. Der Generationenwechsel

Eine neue Generation von Ingenieuren tritt in die Arbeitswelt ein. Sie sind mit Web-Apps, Cloud-Speicher und Echtzeit-Zusammenarbeit (Google Docs, Figma, Notion) aufgewachsen. Sie erwarten, dass ihre professionellen Tools genauso funktionieren.

Wenn ein 25-jähriger Ingenieur ein Büro betritt und eine Windows-XP-Ära Desktop-Anwendung mit einem 300-seitigen PDF-Handbuch überreicht bekommt, ist die Reaktion vorhersehbar: „Es muss einen besseren Weg geben."

3. Die Energiewende

Das Gebäudeenergiegesetz (GEG) und der Druck zu klimaneutralen Gebäuden bedeuten komplexere Berechnungen: Wärmepumpen-Dimensionierung, Integration erneuerbarer Energien, KfW-Förderungsoptimierung. Diese Berechnungen kreuzen mehrere Normen und erfordern Iteration — genau die Art von Workflow, die von Automatisierung und Integration profitiert.

Wie cloudnative TGA-Tools aussehen könnten

Stellen Sie sich eine Welt vor, in der:

Ihre Heizlastberechnung mit Ihrem BIM-Modell kommuniziert. Sie zeichnen einen Raum in Revit, und seine Heizlast wird automatisch in der Cloud berechnet. Ändern Sie den U-Wert eines Fensters im Modell, und die Heizlast aktualisiert sich in Echtzeit.

Normen modular und kombinierbar sind. Sie brauchen die Heizlast (DIN EN 12831), dann die Lüftungsdimensionierung (DIN 1946-6), dann die Wärmepumpen-Dimensionierung (VDI 4645)? Jede Berechnung speist automatisch in die nächste — gleiche Gebäudedaten, keine Neueingabe.

Ergebnisse transparent und prüfbar sind. Jede Zahl verlinkt zurück auf die spezifische Klausel der Norm. Ein Prüfer kann auf „Φ_T = 1.847 W" klicken und genau sehen, welche Hüllflächenkomponenten, U-Werte und Temperaturdifferenzen in dieses Ergebnis eingeflossen sind.

Zusammenarbeit eingebaut ist. Mehrere Ingenieure arbeiten am selben Projekt. Der Tragwerksplaner aktualisiert den Wandaufbau, und die Heizlastberechnung des TGA-Ingenieurs aktualisiert sich entsprechend.

Berichte sich selbst generieren. Die Baubehörde bekommt ein PDF im erwarteten Format — nicht weil der Ingenieur zwei Stunden mit Formatierung verbracht hat, sondern weil das Tool es automatisch erzeugt.

Das ist keine Science Fiction. Das baut Mepbau.

Warum Ingenieure — nicht Softwareunternehmen — diese Tools bauen werden

Die großen AEC-Softwareunternehmen (Autodesk, Trimble, Nemetschek) hätten die Ressourcen, cloudnative TGA-Berechnungstools zu bauen. Aber sie haben es nicht getan. Warum?

Fehlanreize. Ihre Einnahmen kommen aus Desktop-Lizenzverlängerungen. Der Umstieg auf cloudbasiertes SaaS würde bestehende Einnahmequellen kannibalisieren.

Domänenferne. Softwareunternehmen stellen Software-Ingenieure ein, keine HLK-Ingenieure. Zu verstehen, wie DIN EN 12831 funktioniert — wirklich zu verstehen, einschließlich der Sonderfälle und regionalen Variationen — erfordert Jahre an Domänenerfahrung.

Marktfragmentierung. Der DACH-TGA-Markt ist relativ klein verglichen mit Architektur-Design-Software. Der ROI eines cloudnativen DIN EN 12831-Tools rechtfertigt die Investition eines Großkonzerns nicht.

Das schafft eine Lücke für Ingenieur-Entwickler — Menschen, die sowohl die Domäne als auch die Technologie verstehen. Menschen, die jahrelang Heizlastberechnungen von Hand gemacht haben und genau wissen, wo die Schmerzpunkte liegen.

Der schwierige Teil: Vertrauen

Technische Implementierung ist der einfache Teil. Der schwierige Teil ist, das Vertrauen einer Branche zu gewinnen, die verständlicherweise konservativ ist.

Wenn ein Ingenieur eine Berechnung stempelt, haftet er persönlich. Wenn die Heizungsanlage unterdimensioniert ist und das Gebäude im Januar keine 20°C erreicht, trägt der Ingenieur die Konsequenzen — nicht der Softwarehersteller.

Dieses Vertrauen zu gewinnen, erfordert:

1. Transparenz. Jeden Zwischenwert zeigen. Jede Normklausel referenzieren. Den Ingenieur die Mathematik nachvollziehen lassen.
2. Validierung. Benchmark-Ergebnisse gegen Referenzberechnungen und Konkurrenzsoftware veröffentlichen.
3. Konformität. Die exakten Berichtsformate unterstützen, die Baubehörden erwarten.
4. Community. Öffentlich bauen. Methodik teilen. Ingenieure den Ansatz prüfen lassen, bevor sie ihm ihre Projekte anvertrauen.

Der Weg nach vorn

Das Softwareproblem der HLK-Branche wird sich nicht von selbst lösen. Die etablierten Anbieter haben keinen Anreiz, sich selbst zu disrumpieren. Die Normungsgremien veröffentlichen PDFs, keine APIs. Und die Ingenieure, die bessere Tools brauchen, sind zu beschäftigt mit manuellen Berechnungen, um sie selbst zu bauen.

Aber das Fenster öffnet sich. BIM-Mandate treiben die Branche zu digitalen Workflows. Die Energiewende macht Berechnungen komplexer und häufiger. Und eine Generation von Ingenieuren, die mit Code vertraut ist, tritt in die Arbeitswelt ein.

Die Tools, die sie brauchen, müssen cloudnativ, normenkonform, transparent und bezahlbar sein. Sie müssen von Menschen gebaut werden, die sowohl das Ingenieurwesen als auch die Technologie verstehen.

Ich baue eines davon. Wenn Sie die gleiche Chance sehen, freue ich mich auf den Austausch.

Arbeiten Sie an Software für die Bauindustrie? Bauen Sie Tools für TGA-Ingenieure? Schreiben Sie mir an hello@laborsam.com.