Fachbeitrag · Diagnose / Gebäudetechnik

49,7 Tage in der Lüftung

Stand: Juli 2026 · Lesezeit ~4 Min · Praxisfall (anonymisiert)

Comic: Links ein ratloser Techniker vor einer Lüftungsanlage („Power Spikes?“ – die bequeme Erklärung), rechts ein Ventilator mit überlaufendem Zähler („Firmware Overflow“ – die wahre Ursache). Große Headline: 49,7 Tage, Stempel: 32-Bit-Overflow.
Die bequeme Erklärung gegen die wahre Ursache — 49,7 Tage sind der Fingerabdruck eines 32-Bit-Zählerüberlaufs.

Mehrere Lüftungsanlagen in einem Gebäude fielen aus, nicht ständig und nicht unter Last, sondern in einem Rhythmus, den zunächst niemand sah. Erst eine einzige Zahl machte den Fehler eindeutig: 49,7 Tage.

Der Befund

Die Anlagen setzten sporadisch aus und liefen kurz darauf wieder. Auf den ersten Blick wirkte das zufällig — auch weil die einzelnen Geräte zu unterschiedlichen Zeitpunkten in Betrieb gegangen waren und ihre Ausfälle entsprechend versetzt auftraten. Ein Muster war nicht offensichtlich.

Die Erklärung der Betreiber und der beteiligten Fachleute war schnell zur Hand: Spannungsschwankungen, Netzschwankungen, kurze Einbrüche im Hausnetz. Eine bequeme Erklärung — sie schiebt die Ursache nach außen, ist schwer zu widerlegen und verlangt keine Änderung an der Anlage selbst.

Die Zahl, die alles verrät

Trägt man die tatsächlichen Ausfallzeitpunkte je Gerät sauber auf, kommt immer dasselbe Intervall heraus: rund 49,7 Tage ununterbrochener Laufzeit. Und diese Zahl ist kein Zufall, sondern einer der bekanntesten Fingerabdrücke der Digitaltechnik:

232 = 4.294.967.296 Millisekunden
÷ 1000   = 4.294.967,296 Sekunden
÷ 86.400 = 49,71 Tage

Viele eingebettete Steuerungen führen intern einen vorzeichenlosen 32-Bit-Zähler mit, der die Betriebszeit in Millisekunden zählt. Nach exakt 49,71 Tagen ist der Wertebereich erschöpft — der Zähler springt von seinem Höchstwert zurück auf null (ein Integer-Overflow). Wird in der Firmware eine Zeitdifferenz unsauber berechnet, liefert dieser Überlauf plötzlich eine riesige oder negative Zeitspanne. In der Folge schlägt ein Watchdog an, ein Timeout feuert falsch, und die Regelung bleibt stehen. Nach genau derselben Mechanik funktioniert der berühmte alte Windows-95-Bug, der nach 49,7 Tagen Laufzeit zuschlug.

Der entscheidende Punkt: Das ist kein Fehler des Stromnetzes, sondern ein Softwarefehler, der zeitgesteuert und völlig reproduzierbar auftritt, nur eben erst nach sieben Wochen Dauerbetrieb, weshalb er in keinem Prüfstand und keinem Kurztest je erscheint.

Warum der Ausfall „manchmal“ verschwand

Bleibt die Frage, warum die Störung nicht zuverlässig registriert wurde. Die Antwort liegt in der Kette dahinter. Der Ventilator erkannte den Fehler, setzte sich selbst zurück und lief nach kurzer Zeit weiter. Das übergeordnete Gebäudeleitsystem (BMS) ist aber ein vergleichsweise träges System, das seine Datenpunkte nur in größeren Abständen abfragt.

Fiel eine Anlage aus und startete innerhalb dieses Abfragefensters neu durch, bekam das Gebäudeleitsystem davon schlicht nichts mit — der kurze Aussetzer lag genau zwischen zwei Abfragen. Der Ausfall trat also jedes Mal nach 49,7 Tagen auf; ob er gemeldet wurde, war Glückssache. Aus einem harten, periodischen Fehler wurde so ein scheinbar sporadisches Phänomen — perfekt geeignet, die Netzschwankungs-These am Leben zu halten.

Warum man es kaum messen kann

Und selbst mit der richtigen Hypothese im Kopf — „alle 49,7 Tage kippt in einem Embedded-System ein Zähler um“ — hat man mit üblicher Ausrüstung kaum eine Chance, das im Moment des Geschehens zu erwischen. Das eigentliche Ereignis dauert wenige Millisekunden. Man müsste an der richtigen Anlage, im richtigen Signalpfad, exakt in dem Sekundenbruchteil messen, der sich nur alle sieben Wochen einmal öffnet.

Dazu kommt die Bauart der Meldekette. In Lüftungssystemen sind die Alarme meist durchgeschleift und als Summenalarm ausgeführt: Am Ende steht die Aussage „irgendwo in dieser Kette gab es eine Störung“ — nicht, welches Gerät, welcher Kanal, welche Ursache. Die Information, die man zur Diagnose bräuchte, ist auf dem Weg nach oben längst verlorengegangen. Man weiß, dass etwas war, aber weder wo noch warum. Selbst wenn man weiß, wonach man sucht, ist es damit extrem schwer zu finden.

Die Lösung — und ein Stück Zufall

Der entscheidende Hinweis kam am Ende eher zufällig: Beim Auslesen der Geräte fiel auf, dass für die Ventilator-Firmware eine neue Major-Revision vorlag. Das passte zur Hypothese — jemand hatte offenbar genau diesen Zählerüberlauf bis dahin nicht abgefangen und in der neuen Version korrigiert.

Die Ursache lag also nicht in der Elektrik, nicht in der Regelung des Gebäudeleitsystems und nicht im Netz, sondern tief in der Firmware der Ventilatoren. Behoben wurde sie mit dieser großen Firmware-Revision des Herstellers, die die Zeitberechnung überlaufsicher machte. Danach war Ruhe.

Was man daraus mitnimmt

Selbst ein Ventilator ist heute ein eingebettetes System mit eigenem Rechner und eigener Software. Die alte Trennung „Mechanik hier, Elektronik dort“ trägt nicht mehr — der Fehler kann in einer Zeile Code stecken, die niemand in der Anlagentechnik vermutet.

  • Die bequeme Erklärung ist nicht die Diagnose. „Netzschwankungen“ beendet die Suche, statt sie zu führen. Wer die Daten wirklich aufträgt, sieht das Intervall.
  • Zahlen sind Zeugen. 49,7 Tage, 24,8 Tage, 248 Tage — solche Werte sind keine Zufälle, sondern Zweierpotenzen in Zeit übersetzt. Wer sie erkennt, spart Wochen an Fehlersuche.
  • Das Messsystem ist Teil des Problems. Ein träges Gebäudeleitsystem verschleiert kurze, harte Fehler und lässt sie zufällig erscheinen.
  • Ein Summenalarm sagt „irgendwo“, nicht „warum“. Durchgeschleifte Meldeketten verwerfen genau die Information, die man zur Diagnose braucht — die Ursache steckte am Ende in der ausgelesenen Firmware-Version, nicht in einer Alarmmeldung.

Root-Cause-Analyse heißt genau das: nicht die erste plausible Erklärung übernehmen, sondern so lange messen und rechnen, bis die Ursache eindeutig ist — auch wenn sie am Ende in der Firmware eines Lüfters liegt.

Ein wiederkehrender Fehler, den bisher niemand dingfest machen konnte? 15 Minuten zur Klärung →


Hinweis: Praxisfall, anonymisiert. Die 49,71 Tage folgen unmittelbar aus dem Überlauf eines vorzeichenlosen 32-Bit-Millisekundenzählers (232 ms); der Effekt ist in der Embedded-Technik gut dokumentiert (u. a. der Windows-95-Uptime-Bug nach 49,7 Tagen).

← Alle Fachbeiträge