Schedule & Calendar Objekte: Zeitsteuerung in BACnet richtig planen

Die meiste Energie in einem Gebäude wird nicht durch eine falsche Regelung verschwendet, sondern dadurch, dass Anlagen laufen, wenn sie niemand braucht. Eine Lüftung, die am Wochenende auf vollen Touren läuft, eine Heizung, die über die Betriebsferien munter weiterheizt: Solche Verluste entstehen nicht durch defekte Technik, sondern durch fehlende oder schlecht geplante Zeitsteuerung. Genau hier setzen die beiden Objekte an, um die es in diesem Teil geht.

In Teil 5 ging es um das Alarmmodell, also darum, wie eine Anlage meldet, wenn etwas aus dem Ruder läuft. Jetzt geht es um das Gegenstück auf der Betriebsseite: Wie sorgt eine Anlage dafür, dass sie zur richtigen Zeit den richtigen Betriebszustand einnimmt, ganz ohne dass jemand von Hand eingreifen muss. In BACnet erledigen das die Schedule- und die Calendar-Objekte.

Dieser Teil erklärt, wie ein Schedule-Objekt Wochenprogramme und Ausnahmen abbildet, wie es seine Werte an andere Objekte schreibt, wie ein Calendar-Objekt Feiertage und Sonderzeiten zentral bereitstellt und worauf Betreiber bei der Übergabe dieser Zeitprogramme unbedingt achten sollten.

Warum Zeitsteuerung ein eigenes Objekt verdient

Man könnte meinen, Zeitsteuerung sei eine Kleinigkeit, die man irgendwo im Programm einer Steuerung versteckt. Genau das ist das Problem. Wenn Betriebszeiten fest im Programm einer einzelnen Steuerung kodiert sind, sieht man ihnen von aussen nicht an, wann eine Anlage laufen sollte. Niemand kann sie ohne Herstellerwerkzeug prüfen, dokumentieren oder anpassen. Bei einer Nutzungsänderung wird die Anpassung zur Suche nach der Nadel im Heuhaufen.

BACnet macht Zeitsteuerung deshalb zu einem sichtbaren, standardisierten Objekt. Ein Schedule-Objekt ist über das Netzwerk lesbar und beschreibbar, es zeigt offen, welcher Wert zu welcher Zeit gilt, und es lässt sich herstellerunabhängig bedienen. Damit wird aus einer versteckten Programmzeile ein nachvollziehbares Stück Anlagenlogik, das zur Anlagendokumentation gehört.

Der zweite Vorteil ist die Trennung von Zeitplan und geregelter Anlage. Ein Schedule schreibt seine Werte an die Objekte, die er steuert, weiss aber nichts über deren innere Regelung. So bleibt die Zeitsteuerung ein klar abgegrenzter Baustein, den man verstehen und prüfen kann, ohne die gesamte Anlagenlogik zu durchdringen.

Das Schedule-Objekt: das Wochenprogramm

Herzstück des Schedule-Objekts ist das Wochenprogramm, in BACnet die Property Weekly_Schedule. Sie legt für jeden der sieben Wochentage fest, zu welcher Uhrzeit welcher Wert gelten soll. Ein typisches Beispiel: montags bis freitags ab sechs Uhr der Wert für Tagbetrieb, ab neunzehn Uhr der Wert für Nachtabsenkung, am Wochenende durchgehend Nachtbetrieb. Jeder Eintrag besteht aus einer Uhrzeit und dem Wert, der ab dieser Uhrzeit gilt, bis der nächste Eintrag ihn ablöst.

Welchen Wert ein Schedule ausgibt, wenn kein Eintrag greift, bestimmt die Property Schedule_Default. Sie ist der Rückfallwert, etwa der sichere Nachtzustand. Das ist wichtiger, als es klingt: Ohne einen sinnvollen Standardwert kann eine Lücke im Programm zu einem undefinierten Betriebszustand führen. Der Standardwert ist die Absicherung, dass die Anlage immer einen definierten Zustand kennt.

Der aktuell gültige Wert steht jederzeit in der Property Present_Value des Schedule-Objekts. So lässt sich mit einem Blick prüfen, was das Zeitprogramm gerade vorgibt, ohne die gesamte Wochenlogik im Kopf nachrechnen zu müssen. Diese Transparenz ist einer der grössten praktischen Vorteile eines sauber umgesetzten Schedule-Objekts.

Ausnahmen: das Exception_Schedule

Ein reines Wochenprogramm reicht in der Praxis nie aus, denn jedes Gebäude hat Ausnahmen. Feiertage, Betriebsferien, ein Anlass am Samstagabend, ein Wartungstag: All das sind Abweichungen vom normalen Wochenrhythmus. Dafür gibt es das Exception_Schedule. Es überschreibt an bestimmten Tagen das normale Wochenprogramm.

Eine Ausnahme hat immer eine höhere Priorität als das Wochenprogramm. Fällt ein Feiertag auf einen Mittwoch, gilt an diesem Tag nicht das normale Mittwochsprogramm, sondern die Ausnahmeregel, etwa durchgehender Nachtbetrieb. Jede Ausnahme trägt selbst eine Priorität, sodass sich auch mehrere überlagernde Ausnahmen eindeutig auflösen lassen, wenn etwa ein Sonderanlass auf einen Feiertag fällt.

Eine Ausnahme kann sich auf ein einzelnes Datum beziehen, auf einen wiederkehrenden Termin oder auf einen ganzen Datumsbereich. Genau hier entsteht die Verbindung zum zweiten Objekt dieses Teils: Statt jede Ausnahme einzeln im Schedule zu pflegen, kann eine Ausnahme auf ein Calendar-Objekt verweisen und dessen Datumsliste nutzen.

Das Calendar-Objekt: Feiertage zentral pflegen

Das Calendar-Objekt ist im Kern eine gepflegte Liste von Datumsangaben, in BACnet die Property Date_List. Dort stehen die Tage, die eine besondere Behandlung brauchen: gesetzliche Feiertage, Betriebsferien, regelmässig wiederkehrende Schliesstage. Die Einträge können einzelne Daten sein, Datumsbereiche oder Muster wie „jeder erste Montag im Monat“.

Der entscheidende Gedanke ist die zentrale Pflege. Ein einziges Calendar-Objekt hält die Feiertage fest, und beliebig viele Schedule-Objekte verweisen darauf. Wird ein Feiertag einmal im Kalender eingetragen, wirkt er automatisch auf alle angebundenen Zeitprogramme. Das erspart die fehleranfällige Arbeit, dasselbe Datum in Dutzenden einzelnen Schedules nachzupflegen.

Gerade der Jahreswechsel macht den Nutzen sichtbar. Feiertage verschieben sich, Betriebsferien werden neu festgelegt. Mit einem zentralen Calendar-Objekt ist das eine einzige, überschaubare Pflegeaufgabe. Ohne ein solches Objekt beginnt jedes Jahr die mühsame und riskante Suche nach allen Stellen, an denen Feiertage hinterlegt sind.

Ein weiterer Vorteil ist die klare Struktur. Oft lohnt es sich, mehrere Calendar-Objekte für unterschiedliche Zwecke anzulegen, etwa eines für die gesetzlichen Feiertage, eines für die Betriebsferien und eines für regelmässige Sonderanlässe. So bleibt jederzeit nachvollziehbar, warum eine Anlage an einem bestimmten Tag vom normalen Programm abweicht. Ein einziger, unübersichtlicher Sammelkalender mit hundert Einträgen ohne erkennbare Ordnung ist dagegen fast so schlecht wie gar kein Kalender, weil niemand mehr durchschaut, welcher Eintrag welchen Zweck hat.

Wichtig ist ausserdem, dass ein Calendar-Objekt nur die Tage bereitstellt, die eigentliche Betriebsentscheidung aber im Schedule fällt. Der Kalender sagt, dass ein Tag ein Feiertag ist. Was an einem Feiertag geschehen soll, ob die Anlage im Nachtbetrieb bleibt oder ganz abschaltet, legt die zugehörige Ausnahme im Schedule fest. Diese Aufgabenteilung sauber zu verstehen erspart im Betrieb viele Missverständnisse.

Wie ein Schedule seine Werte schreibt

Ein Schedule steuert nicht abstrakt, sondern schreibt konkrete Werte an konkrete Objekte. Welche das sind, legt die Property List_Of_Object_Property_References fest. Dort steht, in welche Eigenschaften welcher Objekte der aktuelle Zeitwert geschrieben wird, typischerweise in den Present_Value der geregelten Objekte, etwa eine Betriebsart, eine Freigabe oder einen Sollwert.

Hier schliesst sich der Kreis zu Teil 2 und Teil 3 dieser Serie, in denen es um das Schreiben mit Prioritäten und um das Priority Array ging. Ein Schedule schreibt seine Werte mit einer bestimmten Priorität über die Property Priority_For_Writing. Damit reiht sich die Zeitsteuerung sauber in die Rangordnung der Schreibzugriffe ein: Ein manueller Eingriff oder eine Sicherheitsfunktion mit höherer Priorität kann den Zeitplan bewusst übersteuern, ohne ihn zu löschen.

Diese Kopplung ist mächtig, will aber verstanden sein. Ist die Priorität des Schedules zu hoch gewählt, lässt sich der Zeitplan von Hand kaum noch übersteuern. Ist sie zu tief, setzt sich eine vergessene manuelle Vorgabe dauerhaft über den Zeitplan hinweg. Die richtige Einordnung der Schreibpriorität gehört deshalb bewusst in die Planung.

Ein Schedule ist keine Regelung

Ein häufiges Missverständnis ist, ein Schedule würde eine Anlage regeln. Das tut er nicht. Ein Schedule gibt nur vor, welcher Wert wann gilt, etwa die Freigabe des Tagbetriebs oder einen Sollwert. Wie die Anlage diesen Wert umsetzt, ob sie also aufheizt, abkühlt oder lüftet, bleibt Sache der eigentlichen Regelung. Der Schedule ist der Taktgeber, nicht der Regler.

Diese Trennung ist bewusst gewollt und ausgesprochen praktisch. Die Zeitsteuerung lässt sich ändern, ohne die Regelung anzufassen, und die Regelung lässt sich optimieren, ohne die Zeitprogramme neu aufzusetzen. Wer diesen Unterschied verinnerlicht, versteht auch, warum ein Schedule allein noch keinen effizienten Betrieb garantiert. Er ist die Voraussetzung dafür, dass die Anlage überhaupt zur richtigen Zeit den richtigen Zustand kennt. Was sie daraus macht, entscheidet das Zusammenspiel mit der Regelung, mit Sollwerten und mit dem Verhalten der Nutzer.

Gerade deshalb lohnt es sich, ein Zeitprogramm nicht als starre Vorgabe zu verstehen, sondern als lebendigen Teil der Betriebsführung. Ein gutes Zeitprogramm bildet die tatsächliche Nutzung ab und wird nachgeführt, wenn sich diese ändert. Ein starres Programm, das seit der Inbetriebnahme unangetastet blieb, passt nach wenigen Jahren oft nicht mehr zur Realität und heizt oder lüftet an der Nutzung vorbei.

Aus der Praxis: die häufigsten Fehler bei der Zeitsteuerung

Bei Schedule- und Calendar-Objekten begegnen uns in Analysen und Abnahmen immer wieder dieselben Schwachstellen:

• Hart kodierte Zeiten. Betriebszeiten liegen versteckt im Steuerungsprogramm statt in einem sichtbaren Schedule-Objekt. Niemand kann sie ohne Herstellerwerkzeug prüfen oder anpassen.
• Fehlende Kalenderintegration. Feiertage sind in jedem Schedule einzeln eingetragen statt zentral in einem Calendar-Objekt. Der Jahreswechsel wird zur fehleranfälligen Grossbaustelle.
• Kein definierter Standardwert. Ohne sinnvollen Schedule_Default führen Lücken im Programm zu undefinierten Betriebszuständen.
• Falsch gewählte Schreibpriorität. Ist Priority_For_Writing zu hoch oder zu tief eingeordnet, lässt sich der Zeitplan entweder nicht übersteuern oder wird von vergessenen Handeingriffen dauerhaft ausgehebelt.
• Unklare Zuständigkeiten. Nach der Übergabe weiss niemand, wer die Zeitprogramme pflegt. Die Feiertage von vor drei Jahren stehen noch immer im Kalender.
• Keine Erklärung bei der Übergabe. Die Zeitsteuerung funktioniert, aber der Betreiber wurde nie eingewiesen und traut sich nicht, etwas zu ändern.

Was Betreiber bei der Übergabe wissen müssen

Zeitprogramme sind kein Objekt, das man einmal einstellt und dann vergisst. Sie leben mit der Nutzung des Gebäudes. Deshalb gehört zur Übergabe zwingend eine Einweisung: Wo finde ich die Schedule-Objekte, wie lese ich ein Wochenprogramm, wie trage ich eine Ausnahme ein und wo pflege ich die Feiertage im Calendar-Objekt. Ein Betreiber, der das selbständig kann, ist nicht bei jeder kleinen Änderung auf einen teuren Serviceeinsatz angewiesen.

Genauso wichtig ist die Frage der Zuständigkeit. Es muss klar sein, wer die Zeitprogramme pflegt und wer den Feiertagskalender jedes Jahr aktualisiert. Ohne benannte Verantwortung veralten die Programme schleichend, und der ursprünglich sorgfältig geplante Energievorteil geht Jahr für Jahr ein Stück weit verloren.

Für Planer und Bauherren bedeutet das: Verlangen Sie sichtbare, dokumentierte Schedule- und Calendar-Objekte statt versteckter Zeiten im Programm, eine zentrale Kalenderpflege und eine echte Einweisung als Teil der Abnahme. Zeitsteuerung ist einer der grössten Hebel für den Energieverbrauch, und sie kostet fast nichts, wenn sie von Anfang an sauber geplant ist.

Wichtig: Massgebend für Objekte und Datenpunkte sind in der Schweiz die KBOB-Empfehlung «BACnet Anwendung», die einschlägigen SIA-Normen der Reihe 386 sowie ISO 16484. Für die Gestaltung von Zeitprogrammen und Betriebszeiten liefert zusätzlich die VDI 3814 wertvolle Hinweise. Viele Betreiber ergänzen diesen Rahmen durch eigene Vorgaben zu Betriebszeiten, Ferienregelungen und Zuständigkeiten für die Pflege.

Fazit

Schedule- und Calendar-Objekte sind das Werkzeug, mit dem BACnet Zeit in Betrieb übersetzt. Das Schedule-Objekt hält das Wochenprogramm und die Ausnahmen, kennt einen sicheren Standardwert und schreibt seine Werte mit definierter Priorität an die geregelten Objekte. Das Calendar-Objekt pflegt Feiertage und Sonderzeiten zentral und versorgt beliebig viele Zeitprogramme aus einer Hand.

Entscheidend ist, dass Zeitsteuerung sichtbar, dokumentiert und gepflegt ist. Ein sauber geplantes Zeitprogramm spart Energie, ohne dass es jemand täglich beachten muss, aber nur, wenn Zuständigkeiten geregelt sind und der Betreiber weiss, wie er es bedient. Zeitsteuerung ist unspektakulär und trotzdem einer der wirksamsten Hebel im ganzen Gebäude.

In Teil 7 geht es um zwei Objekte für die aktive Steuerung: das Loop-Objekt für die PID-Regelung direkt im Gerät und das Command-Objekt für koordinierte Mehrfachbefehle, mit denen sich eine ganze Betriebsart auf einen Schlag umschalten lässt.

Diese Serie ergänzt unsere Serie «BACnet Planung»: «Objekte verstehen» erklärt, was die Objekte sind und wie sie sich verhalten. «BACnet Planung» zeigt, wie man sie in Ausschreibung, Vertrag und Abnahme richtig vorschreibt. Wer beides verbindet, plant und betreibt Gebäudeautomation, die den Namen Interoperabilität verdient.

Sie haben Fragen dazu?

Haben Sie Fragen zu diesem Thema oder zu Ihrer eigenen Anlage? Sprechen Sie uns an, wir unterstützen Sie gerne mit unserer Planungs- und Analyseerfahrung. Eine Übersicht aller Fachartikel finden Sie unter https://wenget.ch/insights/

WENGET, Ihre unabhängige Fachinstanz für BACnet-Planung, -Analyse und -Abnahme in der Schweiz.

Quellenverzeichnis

• ASHRAE Standard 135-2024 (BACnet)
• ISO 16484-5
• KBOB-Empfehlung «BACnet Anwendung» V2.0 (Juli 2021)
• BACnet International: Object Reference (The Language of BACnet)
• VDI 3814 (Gebäudeautomation, Betriebszeiten und Zeitprogramme)
• SIA 386.110
• Eigene Planungserfahrung WENGET