The time schedule is the only function in a building management system that lowers consumption without installing anything. It is also the one that drifts fastest — and the only one whose drift never raises an alarm.
A 6,000 m² office building in Valais. Actual occupancy: 47 hours a week. Ventilation running: 168. The schedule did say 06:00–18:00, and it was correct: three years earlier a technician had forced the air handling unit to run permanently for a handover inspection.
One hundred and sixty-eight hours
A week has 168 hours. An office building is occupied for between 45 and 55 of them. A school, around 35 outside the holidays. A municipal sports hall, between 25 and 60 depending on the local clubs. In every case the majority of calendar time is unoccupied time — and it is the schedule, and the schedule alone, that decides what runs during it.
No other control function has this ratio between cost and effect. Optimising a heating curve takes readings and weeks of steps. Replacing a fan takes an order, a shutdown and a budget. Correcting a schedule takes twenty minutes in front of a supervision screen.
That is precisely what makes it invisible. An item with no cost has no budget line, no purchase order and no handover — therefore no owner.
What you find when you open the schedules
The findings repeat themselves from one building to the next.
- The public-holiday calendar stops at a year that has already passed. Almost every BMS handles a calendar object separate from the weekly schedule; it has to be filled in every year, and nobody has that task in their contract. Past the last date entered, the building heats and ventilates public holidays as working days. In Valais this also covers St Joseph's Day, Corpus Christi, the Assumption and the Immaculate Conception, which appear in no calendar delivered by default.
- The schedules describe a use that has changed. An office floor turned into a training room used two days a week keeps the office floor's schedule. The reverse happens too, and it costs comfort: a room that moved to continuous occupancy keeps an office schedule.
- Overrides have become permanent. An extension set for an evening meeting, a widened band for building works, a switch to occupied mode for an event weekend. The function exists in every BMS; the expiry date rarely does.
- Manual commands have never been released. This is the most expensive case. An output forced to run permanently no longer follows any schedule and reports no fault. It does exactly what it was told — indefinitely.
- The circuits can no longer be identified. “Circuit 3” does not say what it serves. A schedule that cannot be tied to a use will not be corrected: nobody dares touch it, so it stays.
- Optimum start is not enabled, or is enabled badly. Most controllers can calculate the start time from outside temperature and measured thermal inertia. When the function is missing, the schedule is brought forward “to be safe” — and the building is heated two hours too long every morning, 200 days a year.
- The clock itself is wrong. A drift of a few minutes a month on a controller with no synchronisation, a summer-time change not handled on third-party equipment, a substation left on another time zone after a board replacement.
None of these seven points raises an alarm. On the supervision screen, everything is green. A device forced to run is not in fault: it is doing exactly what it was asked to do.
What the standards say
Time control is not a comfort setting: it is an automation function, assessed as such. The Swiss standard SIA 386.110 — which adopts the method of the European standard EN ISO 52120-1 — classifies installations from A to D according to the automation functions actually present and active. Scheduling of emission, distribution and ventilation, together with occupancy-based control, are among the functions that directly determine that class.
The important word is active. A function present in the controller but never configured, or neutralised by a manual command, produces no effect at all. An installation can therefore be designed as class B and operated as class C or D without a single document saying so. That is the most common situation.
On the protocol side the vocabulary exists and is standardised. BACnet (ANSI/ASHRAE 135) defines dedicated objects — Schedule for the weekly programme, Calendar for exception days — and a sixteen-level priority array on every commandable output, where manual and automatic commands do not occupy the same rank. That mechanism is exactly what distinguishes a temporary override from a permanent manual command. It is available in almost every installation, and used in very few.
Setting up a hierarchy
Three levels are enough, provided they are written into the specification and verified at handover.
- The schedule is the reference. It lives in the controller, not in the supervision: a substation cut off from its server must keep respecting its hours.
- The override is a change bounded in time, available to the operator, with a mandatory expiry. An override with no end date must not be accepted.
- The manual command is a maintenance action, at high priority, reserved for technicians, and it must be visible: a list of forced points on the supervision home page, and an automatic alarm as soon as a forced point exceeds an agreed duration — 24 or 72 hours depending on the installation.
An alarm on the duration of a manual command is the only measure that turns a forgotten override into an event somebody deals with. Without it, the hierarchy stays an intention written in a specification.
The audit method
- Export every schedule and every calendar, circuit by circuit. Most systems produce a single file; failing that, screenshots will do.
- List the forced points, at all priorities. This is the first operation, and often the one that explains everything.
- Tie each schedule to a real use and to a person who knows it. Orphan schedules are dealt with last, never first.
- Compare with actual occupancy hours, not declared ones. Access-control records, people counting or simply the trend of a CO₂ sensor settle the question within a week.
- Check the clock and its synchronisation on every controller, including third-party equipment connected through a gateway.
- Reprogramme, then write the annual calendar review into the operating contract. Without that last line, the same audit will be repeated identically in three years.
The table to reuse
This table is annexed to the specification and filled in with the operator. It then becomes the reference document for handover, and afterwards for the annual review.
| Circuit / plant | Area served | Actual occupancy | Schedule | Exception days | Optimum start | Override allowed | Owner |
|---|---|---|---|---|---|---|---|
| AHU 01 | Offices, levels 1–2 | Mon–Fri 07:00–18:00 | Mon–Fri 06:30–18:30 | Valais holiday calendar | Yes | Operator, 4 h max | Property manager |
| Heating circuit 1 | Offices, levels 1–2 | same | Mon–Fri, setback 19:00–05:00 | Valais holiday calendar | Yes | Operator, 24 h max | Property manager |
| AHU 02 | Multi-purpose hall | On booking | Outside schedule, on request | — | No | On booking | Municipality |
| Heating circuit 3 | To be identified | Unknown | Continuous | None | No | — | — |
The last row is the one that matters. A circuit with no identified use runs continuously because nobody dares stop it. Naming it in a signed table is what finally triggers the investigation.
What it changes
The order of magnitude deserves an honest statement: correcting schedules does not refurbish a building. On an installation whose schedules have drifted, the reduction applies to the running hours of the auxiliaries and to unnecessary warm-up periods — a real, measurable saving, obtained without investment.
But the main gain lies elsewhere. A building in which every circuit has an identified use, a justified schedule and a named owner is a building that can be tuned. Until that table exists, every subsequent optimisation — heating curve, variable flow, free cooling — will apply to an installation that runs, in any case, three times longer than it needs to.
wall-i is an independent engineering office for BMS and building automation, based in Valais, Switzerland. Our specifications are open to every brand and our deliverables follow the SIA standards and the KBOB naming convention. A subject you would like us to cover: hello@wall-i.ch