Werkzeug oder Zerrspiegel?

Mit der EnEV 2007 wurde die DIN V 18599 – Ener­getische Bewertung von Gebäuden als Verfahren zur Berechnung von Energiebedarfswerten und zur Erstellung von bedarfsorientierten Energieausweisen für Nichtwohngebäude eingeführt. Zahlreiche Daten sind zu berücksichtigen und das Rechenverfahren ist komplex, sodass der Einsatz von Software zwingend erforderlich ist.

Die fachlichen Anforderungen sowohl an die Software-Entwickler als auch an die -Anwender sind mit der Einführung der DIN V 18599 als Rechenvorschrift für öffentlich-rechtliche Nachweise erheblich gestiegen.

Aufgrund des Zeitdrucks, der zur EnEV 2007 und zur DIN V 18599 geführt hat, und der Schwierigkeit, in einem einzigen Rechenverfahren Heizung, Kühlung und Beleuchtung energetisch abbilden zu wollen, drängt sich die Frage auf, ob die Umsetzung des Rechenverfahrens in Software schon so ausgereift ist, dass die Anwender Planungssicherheit beim Nachweis haben.

Einfaches Bürogebäude als Grundlage

Im Rahmen einer Bachelor-Arbeit an der HAWK Hildesheim wurde von April bis Juni 2008 an einem Bürogebäude untersucht, inwieweit sechs verschiedene Rechenprogramme (Abb.1) bei gleichen gebäude- und anlagentechnischen Eingaben auch gleiche Ergebnisse bei der Überprüfung der öffentlich-rechtlichen Anforderungen gemäß EnEV 2007 liefern. Weiterhin sollte soweit wie möglich den Ursachen auftretender Abweichungen auf den Grund gegangen werden. Vier der eingesetzten Programme verwenden den Kernel des Fraunhofer Instituts für Bauphysik. Zwei haben die Rechenroutinen selbst implementiert.

Als Beispielgebäude wurde ein einfaches Bürogebäude gewählt, damit das Risiko von Eingabefehlern möglichst ausgeschlossen werden konnte. Die Rechenergebnisse wurden mehrfach kontrolliert. Gleichwohl können Fehler nie ganz ausgeschlossen werden. Vermutlich steigt aber bei komplexeren Gebäuden die Fehlerhäufigkeit mit der Anzahl der Zonen. Das Gebäude verfügt über zwei Vollgeschosse und einen thermisch nicht konditionierten Keller, in dem sich auch der Hausanschlussraum befindet (Abb.2).

Die Technik wurde so gewählt, dass alle in der DIN V 18599 behandelten technischen Gewerke im Nachweis abgebildet werden können. So werden z.B. die südseitigen Büroräume (Abb.3) gekühlt, obwohl es sicher möglich und sinnvoll wäre, ein derartiges Gebäude so zu planen, dass auf eine zusätzliche Kühlung verzichtet werden kann. Um einen Anreiz dafür zu schaffen, ist in der EnEV 2007 der Primärenergiebedarf des Referenzgebäudes für Büroflächen zu Null gesetzt. Dies soll sich in der EnEV 2009 bereits wieder ändern.

Es wurden keine „exotischen“ technischen Komponenten verwendet. Die Haustechnik konnte komplett nach DIN V 18599 abgebildet werden und dürfte deshalb für die EnEV-Software keine ernsthafte Hürde darstellen.

Das Gebäude wurde in fünf Zonen aufgeteilt. Die Zone „Büro Nord“ ist beheizt und durch eine RLT-Anlage belüftet. Die Zone „Büro Süd“ (Abb.3) ist beheizt und mittels RLT und Kühldecken gekühlt. Die Raumlufttechnik stellt dabei den Mindestluftwechsel vollständig bereit. Der Sanitärbereich bildet eine nur beheizte Zone (Abb.4). Die Zone „Verkehr“ enthält nach der Drei-Prozentregel auch die Teeküchen im Eingangsbereich der Sanitärbereiche. (Anmerkung der Redaktion: mehr dazu im Beitrag „Zonierung von Nichtwohngebäuden“ in GEB 4 und 5/2008).

Die Zone „Keller unkonditioniert“ wurde angelegt, da im Kühlfall die vereinfachte Berechnung der Transmission über die Kellerdecke mit F_x-Faktoren nach DIN V 18599-2 nicht zulässig ist. In diesem Fall muss die Innentemperatur der thermisch nicht konditionierten Zone monatsweise aus ihren äußeren und inneren Wärmequellen und Wärmesenken ermittelt werden.

Die Norm stellt an einigen Stellen mehrere Rechenverfahren alternativ zur Verfügung (z.B. zur Ermittlung des Luftvolumens, der wirksamen Speicherkapazität C_wirk., der elektrischen Bewertungsleistung der Beleuchtung, der Leitungslängen). Soweit sich dies im jeweiligen Programm beeinflussen lässt, wurde in allen Programmen nach den gleichen Verfahren gerechnet.

So wurde z.B. grundsätzlich das Luftvolumen mit V_i = A_NGF · h_Raum genau berechnet und nicht mit V_i = 0,8·V_e vereinfacht. Die wirksame Speicherkapazität wurde pauschal als „leicht“ angenommen. Die elektrische Bewertungsleistung für das Kunstlicht wurde nach dem Tabellenverfahren berechnet und Wärmebrücken mit einem pauschalen Zuschlag von ΔU_WB = 0,10 W/(m²K) berücksichtigt.

Für die Länge der Verteilungsleitungen der Zweirohr-Heizung wurden anhand der Bauzeichnungen realistische Planungsgrößen eingegeben, da die Standardwerte der Norm unrealistisch große Leitungslängen ergeben hätten. Die Verluste der Verteilungsleitungen sollten dabei der thermisch nicht konditionierten Kellerzone zugeordnet werden. Die Verluste von Strang- und Anbindeleitungen im beheizten Bereich wurden den beheizten Zonen proportional zur thermisch konditionierten Nettogrundfläche zugeordnet. Für das Referenzgebäude muss allerdings gemäß EnEV 2007 mit den Standardwerten der Rohrleitungslängen gerechnet werden.

Große Unterschiede bei den Ergebnissen

Verglichen wurden die Ergebnisse der mit den Programmen erstellten Energieausweise. Die Darstellung erfolgt anonym, da es nicht das Ziel war, einzelne Softwarehersteller an den „Pranger“ zu stellen, Ohnehin lässt sich aus dem Vergleich der Ergebnisse nicht ableiten, welche Software im Sinne der EnEV und DIN V 18599 richtig rechnet. Einzelne Fehlfunktionen konnten in jedem der untersuchten Programme festgestellt werden. Die Softwarehersteller wurden darüber unterrichtet. Aus Sicht des Anwenders bleibt festzustellen: sowohl der geforderte als auch der vorhandene Jahres-Primärenergiebedarf sowie der Transmissionswärmebedarf unterscheiden sich erheblich.

So reicht allein die Bandbreite des ermittelten Primärenergiebedarfs Q_P für das nachzuweisende Gebäude von 216 bis 279 kWh/(m²a) (Abb.5). Die Extremwerte des Anforderungswertes an den Primärenergiebedarf Q_P,EnEV liegen mit 191 und 330 kWh/(m²a) sogar noch weiter auseinander. Das betrachtete Beispielgebäude hätte den Nachweis in den Programmen A und B knapp bestanden. Mit C werden nur 85 % des im Programm ermittelten Anforderungsniveaus erreicht, und bei D (116 %), E (106 %) und F (122 %) wären zusätzliche Maßnahmen notwendig, um die EnEV-Anforderungen zu erfüllen.

Nach DIN V 18599 Teil 1 sind die Endergebnisse Q_P auf ganze Zahlen zu runden. In den Energieausweisen aus den Programmen wird jedoch das Ergebnis mit einer Nachkommastelle ausgewiesen. Dies suggeriert eine Genauigkeit, die angesichts der in (Abb.5) auftretenden Unterschiede grotesk zu nennen ist und die das Verfahren selbst bei fehlerfreier Software und Datenaufnahme vermutlich nicht erreichen kann.

Programm A, B, C und D nutzen den Fraunhofer Kernel. Dass gerade diese vier sich nicht auf ein ähnliches Niveau bei den Ergebnissen „einpendeln“, ist erstaunlich. Zumindest zeigt es, dass der gemeinsame Rechenkernel allein noch keine gleichen Ergebnisse garantiert. Bei der Vielzahl der zu vernetzenden Daten scheint auch in der Verknüpfung von grafischer Programmoberfläche und Rechenkern ein Fehlerpotenzial zu liegen. In Programm C konnten allerdings Teile der Anlagentechnik gar nicht abgebildet werden, sodass hier kein vergleichbarer Primärenergiebedarf erwartet werden konnte.

Die Ursachen der Abweichungen konnten nur teilweise festgestellt werden. Zwischenergebnisse und verwendete Rechenalgorithmen werden von den Programmen unterschiedlich detailliert dokumentiert – in keinem Fall jedoch ausreichend, um die Berechnung vollständig nachvollziehen zu können.

Für das Referenzgebäude werden bei vier Programmen kaum mehr als die Endergebnisse ausgegeben. Ob es also Fehler schon in der Umsetzung des Referenzgebäudes durch die Software gegeben hat, kann vom Anwender nicht überprüft werden.

Am Beispiel des Primärenergiebedarfs für Trinkwarmwasser können detailliert Fehler nachgewiesen werden. Der auf die Hauptnutzung (302,12 m² Bürofläche) bezogene Nutzenergiebedarf Trinkwasser ergibt mit 30 Wh/(m²d) für 250 d/a bezogen auf 474 m² gesamte thermisch konditionierte Nettogrundfläche: Q_w,b = 4,78 kWh/(m²a).

Schon die Ergebnisse des Nutzenergiebedarfs unterscheiden sich bei zwei Programmen erheblich (Abb.6). Vier der sechs Programme ermitteln den Nutzenergiebedarf richtig. Erschreckend sind jedoch die Unterschiede des Endenergiebedarfs (Q_w,f = 8,4 bis 27,9 kWh/(m2a).

In Einzelfällen konnten konkrete Fehler in der Software bzw. abweichende Auslegungen sowohl der EnEV als auch der geltenden Normen als Ursache festgestellt und nachvollzogen werden. So konnten Fehler bei der Berechnung des Anforderungswerts H_T‘ eindeutig geklärt werden (Abb.7). Bei Programm E tritt ein Fehler bei der Ermittlung der wärmeübertragenden Umfassungsfläche A auf. Hier wurde die Kellerdecke nicht mit in A eingerechnet. Aufgrund des veränderten A/V_e-Verhältnisses kommt es somit zu einem abweichenden Anforderungswert H_T‘,EnEV. Bei Programm F wird als Fensterflächenanteil 22 % ausgegeben. Offensichtlich wurde dabei die waagerechte Dachfläche in die Wandfläche eingerechnet. In der Folge entsteht ein schärferes Anforderungsniveau an H_T‘ mit 0,58 W/(m²K) statt 0,80 W/(m²K), da der Fensterflächenanteil f nun kleiner als 30 % ist. Gemäß EnEV 2007 Anlage 2 2.7 ist: „Der Fensterflächenanteil [...] entsprechend Anlage 1 Nr. 2.8 Satz 1 zu ermitteln.“ Für Nichtwohngebäude sind danach Dachflächen bei der Ermittlung des Fensterflächenanteils grundsätzlich nicht zu berücksichtigen.

Nachbesserungen dringend erforderlich

Wie diese beiden Beispiele zeigen, gibt es zum Teil noch ganz triviale Fehler in der Software. Bedarf zur Nachbesserung besteht z.B. bei folgenden Bereichen:

• fehlerhafte Umsetzung der DIN EN ISO 13370 (Wärmetechnisches Verhalten von Gebäuden – Wärmeübertragung über das Erdreich)
• fehlerhafte Umsetzung der charakteristischen Längen, Breiten und Höhen in den Zonen bzw. im Gebäude
• falsche U-Wert-Ermittlung für Fenster in Bezug auf die Regelungen der Bauregelliste
• falsche Zuordnung der „Bauschwere“. Die Bauschwere muss für die Zonen ermittelt werden können. In einem Programm war diese nur für das Gebäude pauschal definierbar
• unvollständige Umsetzung der DIN EN ISO 6946 (Bauteile – Wärmedurchlasswiderstand und Wärmedurchgangskoeffizient)
• lückenhafte Umsetzung von geltenden Normen in der Software – mit Auswirkungen auf die Möglichkeiten der Zonierung, z.B. fehlt die Umsetzung der DIN EN 13363-2 (Sonnenschutzeinrichtungen in Kombination mit Verglasungen – Berechnung der Solarstrahlung und des Lichttransmissionsgrades) zur Bestimmung des g_tot-Wertes
• fehlende Umsetzung der DIN 4108-2 für den sommerlichen Wärmeschutznachweis und fehlende Umsetzung der DIN EN 13947 (Wärmetechnisches Verhalten von Vorhangfassaden – Berechnung des Wärmedurchgangskoeffizienten)

Fehlerfreie Software allein würde jedoch noch nicht genügen, sicher dieselben Ergebnisse zu erzeugen. Zu einer weiteren Streuung der Ergebnisse tragen bei:

• unauffällige und zum Teil auch offensichtliche Eingabefehler durch die Software-Anwender
• keine angemessene Möglichkeit der Eingabekontrolle oder gar Kontrolle der Berechnung
• Fehlinterpretationen und Interpretationsspiel­räume der Normen und der Verordnung
• Zahlreiche offene Fragen zur EnEV 2007, wie z.B. Zulässigkeit der Anpassung von Nutzungsprofilen, klare Trennung zwischen Wohn- und Nichtwohngebäuden, klare Definition der Randdaten zur Ermittlung von Geometriedaten, klare Definition des charakteristischen Bodenplattenmaßes B’ (wird dieses zonen- oder gebäudebezogen ermittelt?), klare Zuordnung der Nachweissystematik bei Gebäuden mit unterschiedlichen Temperaturen innerhalb des Gebäudes (> 12 °C und> 19 °C)

Ein einfacheres, nachvollziehbares Berechnungsverfahren, das in einem angemessenen zeitlichen Rahmen absolviert werden kann, ist dringend erforderlich. Gerade in den frühen Phasen der Planung werden Werkzeuge benötigt, die eine schnelle und trotzdem zuverlässige Bewertung verschiedener Varianten zulassen. Hiervon sind wir derzeit weit entfernt.

Fazit

Die im Rahmen der Bachelor-Arbeit festgestellte Bandbreite der Ergebnisse für das untersuchte Gebäude ist für die Anwender solcher Software erschreckend. Doch auch für Auftraggeber wirft sie unvermittelt die Frage nach dem Sinn derartiger Nachweise auf. In einigen Bundesländern werden öffentlich-rechtliche Nachweise geprüft. Mögliche Rechtswirkungen zwischen den Planern und Auftraggebern – auch in Bezug auf die nach Landesrecht zuständigen Stellen bzw. Haftungsansprüche auch an den Softwarehersteller sind juristisch noch nicht geklärt.

Die Lösung der Probleme ist vermutlich so vielschichtig wie die Bandbreite der Fehler. Eine wesentliche Forderung besteht darin, dass die Ergebnisse für den Anwender so aufbereitet werden, dass Plausibilitätsprüfungen durchgeführt werden können. Hierzu müsste das Verfahren jedoch deutlich vereinfacht ­werden.

Es besteht die berechtigte Frage, warum das Excel-Tool, das schon einmal mit einem finanziellen Aufwand programmiert worden ist, nicht fortgeschrieben wurde, sodass ein „Musterprogramm“ als Vorgabe für andere Benutzeroberflächen verwendet werden könnte.

Kurzfristig ist keine Vereinfachung der Begleitnormen und des Nachweisverfahrens zu erwarten. Deshalb müssen Planungshilfen erarbeitet werden, die eine sichere Handhabung der Materie ermöglichen.

Die Autoren danken den Softwareherstellern für die freundliche Unterstützung und Kooperation.

Dipl.-Ing. Arch. Stefan Horschler

arbeitete nach seinem Architekturstudium an der Universität Hannover von 1992 bis 1999 im Architektur- und Ingenieurbüro für Bauphysik von Univ.-Prof. W.-H. Pohl. Seit 1999 führt er ein eigenes Ingenieurbüro für Bauphysik in Hannover. Er ist Leiter von Fortbildungsveranstaltungen für Industrie- und Handwerkskammern sowie für Inge­nieur- und Architektenkammern und Mitarbeiter diverser Normenausschüsse.

B. Eng. Peter Buschbacher

studierte nach dreijähriger traditioneller Wanderschaft als Schreinergeselle 2004 bis 2008 Holzingenieurwesen (konstruktiver Holzbau) an der HAWK Hildesheim, Abschlussarbeit „Vergleichende Untersuchung nach DIN V 18599“.