BAS Time Sync: Stop Clock Drift Wrecking Your System

When I worked for NASA’s Jet Propulsion Laboratory in Pasadena, time wasn’t a setting, it was a coordinate. Down the hall from the clean rooms, a chilled rack hummed along while everyone casually called it “the atomic clock.” It wasn’t a grandfather clock with hands; it was a reference so stable you could plan a Mars maneuver around it.

Here’s why that matters:

• The Deep Space Network measures signals that left a spacecraft minutes ago and crossed millions of kilometers.

• If your clock is off by 1 microsecond, your range calculation is off by ~300 meters.

• Stack a few microseconds and you’re literally pointing antennas at the wrong patch of sky.

In space, time errors become distance errors.

In buildings, time errors become comfort, energy, and trust errors.

We don’t need nanoseconds in BAS. But we do need the same minute, everywhere, all the time.

Atomic Clock, 30-second explain-it-like-a-tech

An atomic clock uses the ultra-stable vibration (frequency) of atoms, most commonly cesium or hydrogen, as its time base. Hydrogen masers offer incredible short-term stability; cesium sources anchor long-term accuracy; GPS and national labs (NIST) tie them to worldwide UTC. JPL’s timing stacks mix these references so the whole system agrees on “now” to absurd precision. That’s the point: every instrument trusts the same time boss.

Why you should care in BAS

Swap “antenna” for air handler, “spacecraft” for VAVs, and “microsecond” for minutes, and you’ve got our world. If the clocks don’t agree, your warm-up, alarms, trends, DR windows, and compliance all start lying.

Five minutes late isn’t five minutes late in BAS. It’s a broken morning warm-up. It’s a chiller starting at lunch. It’s alarms you can’t trust, trends you can’t prove, and technicians arguing over screenshots that “don’t match” because every device thinks the universe runs on its private clock.

I once walked into a site where the supervisory server, three JACEs, and a fleet of BACnet controllers were each telling time with their own unique accent. Schedules looked fine. Graphics looked fine. But rooms were cold at 8:05 a.m., then stifling by noon, and maintenance swore the system had a ghost. The fix? Not a reprogram. Not a valve. Time sync. We unified the clocks and the “haunting” evaporated.

If your building acts smart one hour and dumb the next, especially around shoulder season, school startup, or Daylight Saving shifts, this is likely your root cause. Today we’re going to end the chaos with a practical, field-ready playbook for BAS time sync that scales from a single RTU to a campus.

Why BAS time sync is a mission-critical control loop

• Schedules: If the AHU thinks it’s 6:00 a.m. but the VAVs think it’s 7:10 a.m., your warm-up turns into a tug-of-war.

• Trends & FDD: Misaligned timestamps make cause-and-effect unreadable. Your economizer “opened” after the compressor “staged,” except those events happened on two clocks.

• Alarms & compliance: Time-stamped events are your legal and operational record. If times wander, your record is suspect.

• Demand response & utility rates: Peak windows, occupied purge, and DR signals are time-anchored. Drift = dollars.

• Cyber forensics: You can’t investigate what you can’t line up. Reliable time is table stakes for security analysis.

Bottom line: time sync isn’t a “nice to have.” It’s the backbone of reliable control.

Where time goes wrong (and how it shows up in the field)

1. No authority tree. Every device points everywhere, or nowhere, for NTP/SNTP.

   Field symptom: Random offsets (+/- 1–30 minutes) across the site, worst after power events.

   
   

2. Supervisory vs device clocks disagree. The station is “correct” but children never sync (or vice versa).

   Field symptom: Schedules “look right” in the supervisor but boxes don’t follow.

   
   

3. MSTP islands never sync. IP devices sync; MSTP controllers ride the token and pray.

   Field symptom: Floor with MSTP VAVs drifts more each week, especially after outages.

   
   

4. Virtual machines inherit bad time. Hypervisor drift or wrong host settings leak into your BAS VM.

   Field symptom: Station time walks minutes per day; reboot temporarily “fixes” it.

   
   

5. Timezone/DST inconsistency. Half the site in UTC, half in local; some devices ignore DST entirely.

   Field symptom: Twice-yearly chaos, early releases, chilled water at 3 a.m., phantom reheat.

   
   

6. Two time sources fight. Devices bounce between NTP servers with different accuracy/stratum.

   Field symptom: Step jumps (e.g., instant +7 min correction) during the day; trends with double timestamps.

   
   

7. Firewall blocks UDP 123 intermittently. NTP allowed today, denied tomorrow by a change.

   Field symptom: Time perfect for a week, then falls off a cliff.

   
   

8. SNTP/NTP client bugs or age. Old firmware “checks once at boot” or can’t slew time gradually.

   Field symptom: Time only correct right after a reboot; later it’s off by minutes.

The 60-minute BAS time sync audit (copy, paste, and run)

Objective: Map who trusts whom, align every device to a vetted source, verify, and lock it down.

0–10 min: Draw the authority tree

• Choose your site time authority (see “Good–Better–Best” below).

• One diagram: External → Core (on-prem) → Supervisor(s) → Controllers.

• Note device types: Supervisor/Server, JACE/Edge, BACnet IP, BACnet MS/TP, LON, Modbus gateways, room controllers.

10–20 min: Inventory what the devices believe

• For each layer, record: current date/time, timezone, DST rule, NTP/SNTP target(s), last sync, and offset from a known-good handheld or your laptop tied to the authority.

• Pro tip: Create a point or station page called “Now() board” that echoes the device’s notion of now in visible text.

20–35 min: Set the rules

• Pick exactly 1–2 NTP servers per site (primary + secondary).

• Force a single timezone (local site timezone) for user-facing devices; allow UTC on data lakes/databases if needed.

• DST policy: If devices support DST, enable the same rule everywhere. If not, schedule around it (more on that below).

• For MSTP, decide: supervisor-push (BACnet TimeSynchronization) vs controller-pull (SNTP/parent).

35–50 min: Configure and verify

• Configure NTP/SNTP on supervisors, edges, and controllers.

• For BACnet devices, enable supervised TimeSynchronization (UTC preferred where supported).

• Slew vs step: Where the device supports it, apply slew (gradual correction) during the day; reserve step (instant jump) for off-hours or when offset >5–10 minutes.

• Push time now; watch offsets shrink to <1 second for IP and <2–5 seconds for MSTP islands.

50–60 min: Lock and log

• Add a weekly Time Health report: device offset, last sync, source, pass/fail.

• Trend a time delta point (device now – supervisor now).

• Add alarms: Offset >60s for 60 min, No sync for 24h, Multiple sources detected.

Good–Better–Best: time architectures that actually work

Good (small site):

• Supervisor/Server syncs from a reputable external NTP (through the firewall).

• All IP controllers point to the supervisor.

• MSTP controllers get time from their IP parents or via periodic BACnet TimeSynchronization broadcast from the supervisor.

Better (most campuses):

• On-prem NTP server (physical appliance or hardened Linux/Windows time server) syncs upstream; supervisor and everything else sync to it.

• Two sources defined (primary on-prem, secondary on-prem or trusted DC).

• Firewall allows outbound UDP 123 from the on-prem time server only; all others blocked.

Best (resilient + precise):

• Two redundant on-prem NTP servers (different racks/circuits), ideally GPS-disciplined so they keep time during WAN outages.

• Supervisors, JACEs, and controllers reference both (primary/secondary).

• For ultra-precise needs (rare in BAS), PTP (Precision Time Protocol) inside the plant network, NTP at the perimeter for everything else.

Field rule: Everything on site trusts one small set of on-prem authorities. Those authorities trust the outside world. Nothing else talks to the Internet for time.

The “BAS time sync” configuration by layer

Supervisors / Servers (Niagara stations, enterprise front ends)

• Set OS time to local timezone (e.g., America/New_York).

• Configure the host OS to use the on-prem NTP pair.

• If virtualized, set hypervisor time correctly; disable guest time drift overrides if you manage time inside the guest.

• Station displays a Now() widget in the header so techs can spot wrong time instantly.

JACEs / Edge controllers

• Set timezone and DST if supported.

• SNTP target = on-prem NTP pair (never random Internet pools).

• If acting as a BACnet time master, enable UTC TimeSynchronization at a reasonable cadence (e.g., 15–60 minutes).

BACnet IP devices

• Prefer native SNTP to the on-prem authorities.

• Fallback: accept BACnet TimeSynchronization from the supervisor.

• Confirm Local Time/Date objects reflect the intended timezone.

BACnet MS/TP devices

• Decide the time master on each trunk (often the JACE/field controller gateway).

• Schedule a synchronization broadcast periodically (not just at reboot).

• If firmware only updates time at restart, plan a controlled off-hours reboot after you set the master.

Other protocols (LON, Modbus, proprietary)

Many don’t support time pull; rely on the supervisor to stamp data with its correct time, and keep the human UIs aligned.

Daylight Saving Time (DST) without drama

Devices that handle DST: Enable the correct rule once, verify the next transition date, and stop touching it.

Devices that don’t handle DST:

• Keep device time in standard time year-round.

• Adjust schedules seasonally (offsets) or let the supervisor translate timestamps for UI/reporting.

• Avoid twice-yearly “manual clock parties.” That’s how drift creeps back.

During the DST shift:

• Prefer to slew through the one-hour change where supported (supervisor and servers).

• For controllers that step, schedule the step in unoccupied and verify the next morning.

Proving it worked: acceptance criteria

• Offset:

  • Supervisors/servers/JACEs: within ±1 second of each other.

  • IP controllers: ±2 seconds.

  • MS/TP controllers: ±5 seconds (±10 if the trunk is long/loaded).

• Sync stability: No device goes >60 seconds offset for more than an hour without an alarm.

• Failover: If the primary NTP is unplugged, devices move to secondary within 15 minutes without step jumps >60 seconds during occupied hours.

• DST event: Next DST change date/time is correct across all devices two weeks before the event.

Troubleshooting time sync like a pro

Symptom: Trends misaligned by a consistent number of minutes.

Cause: Two authorities with different offsets.

Fix: Point everything to the same pair; remove tertiary “mystery servers.”

Symptom: Time perfect after reboot, then drifts 2–5 minutes per day.

Cause: Device only syncs at boot; SNTP task disabled; bad firmware.

Fix: Enable periodic sync; update firmware; if no option, schedule a weekly off-hours sync-reboot until you can replace.

Symptom: Sudden +7 minute jump during the day.

Cause: NTP step instead of slew; controller switched sources.

Fix: Force slew where supported; make sources consistent; schedule manual step after hours.

Symptom: MSTP floor is always late to class.

Cause: No periodic TimeSynchronization on that trunk.

Fix: Gateways broadcast UTC time every 30–60 minutes; verify token can complete a loop under the interval.

Symptom: Twice-yearly chaos.

Cause: Mixed DST policies; some devices in UTC, others local.

Fix: Standardize DST policy; move data storage to UTC if you must split.

Security and reliability guardrails (don’t skip)

• Firewalling: Only on-prem NTP servers talk out to the Internet on UDP 123. Everything else syncs inward.

• Logging: Enable NTP logs on servers; keep 30–90 days of history.

• UPS: Put time authorities on UPS so they don’t reset during brief blips.

• Patching: Keep NTP/chrony/Windows Time patched. Old NTPd has had ugly CVEs.

• Change control: Any network change that touches DNS, firewall, or routing can break time. Add a “Verify NTP” checkbox to your change checklist.

Implementation playbook: 1-day rollout for a medium site

Morning (2 hours)

1. Choose the on-prem time authority (or stand one up).

2. Lock firewall policy (only the authority talks to the outside).

3. Fix OS/hypervisor time on servers; point to authority.

Mid-day (2 hours)

4. Configure supervisors/JACEs to SNTP against authority.

5. Set timezone + DST consistently; expose Now() on all UIs.

6. Enable BACnet TimeSynchronization (UTC) from each trunk head.

Afternoon (2 hours)

7. Repoint IP controllers.

8. Broadcast time to MSTP trunks.

9. Trend offsets; set alarms.

Evening (1 hour, if needed)

10. For stubborn controllers, schedule off-hours step and/or reboot.

11. Send the “Time Health” report to the customer with offsets and pass/fail.

ROI: why your boss (and your future self) will love this

• Fewer callbacks: Morning warm-up and purge windows hit on the dot.

• Faster diagnosis: Trends/alarms become trustworthy evidence.

• Energy wins: Demand windows, DR events, and optimal start/stop behave.

• Compliance: Time-stamped records that withstand audits.

• Happiness: Techs stop arguing about screenshots and start fixing things.

BAS Time Sync FAQ (for the real world)

Q: Is SNTP “good enough” for BAS?

A: Yes. We’re not trading nanoseconds. Consistent seconds-level accuracy beats sporadic “precision” every time.

Q: Do I need GPS?

A: Not required, but GPS-disciplined on-prem NTP gives you resilience during WAN outages.

Q: UTC or local?

A: UI and schedules in local keep sanity; long-term data lakes and analytics in UTC keep math honest across DST and multi-site rollups.

Q: How often should devices sync?

A: Supervisors hourly; controllers every 30–120 minutes; MSTP via broadcast every 30–60 minutes.

Q: What about Daylight Saving changes?

A: Standardize: either every device handles DST the same way, or you hold device time constant and adjust schedules centrally.

The 20-minute “Time Sync or Die” field checklist

• Pick the on-prem time authority (primary + secondary).

• Standardize timezone + DST across supervisors and controllers.

• Point all devices to the same NTP/SNTP pair.

• Enable BACnet TimeSynchronization (UTC) from each trunk head.

• Verify offsets: server ±1s, IP ±2s, MSTP ±5s.

• Add Time Health trends/alarms (offset, last sync).

• Test failover (pull primary; watch devices fall to secondary without step).

• Document the tree; export a one-page Time Authority Map and leave it in the project share.

Wrap it up

If your building feels moody, don’t start with valves or VFDs, start with BAS time sync. Make one set of machines the time adults in the room, point everything else at them, and enforce the rule with alarms. The system gets calmer. Your trends become evidence. And September stops feeling haunted.