BMS Trend Logs vs Historians: Which One You Actually Need

There is a conversation that happens on almost every estate that starts taking its building data seriously. Somebody proposes a historian or a time-series platform, and somebody else quite reasonably points out that the BMS has been logging trends for years and nobody has ever been unable to look something up. Both positions are defensible, and the argument usually goes nowhere because the two sides are answering different questions.

The message up front: controller and head-end trend logs are built for operating a building, and they are very good at it. They are bounded in duration, scoped to one system, and tied to the lifecycle of the equipment and software that holds them. A historian exists to answer questions across systems, across sites and across years. If your questions are all inside one system and inside the trend window, you do not need a separate store yet. The moment a question crosses a boundary, you do, and no amount of configuration will get you there.

1. What a trend log is actually for

A trend log is an operating tool. Its job is to let somebody look at the last stretch of a point's behaviour while they are deciding what to do about it. That purpose explains every one of its properties.

• It is bounded, usually by record count. A log is configured to hold a fixed number of samples and overwrites the oldest when full, which means its duration is a consequence of its interval rather than a policy. Shorten the interval to see more detail and you silently shorten the history.
• It lives where the point lives. Logging is configured per object, on a controller or in the supervisory software, which makes it excellent for that point and unhelpful for comparing across controllers.
• It is scoped to the system that created it. A trend in the HVAC head end does not sit next to one from the metering system or from access control, and nothing joins them.
• It shares the lifecycle of the software. A head-end replacement, a controller swap or a version upgrade can end the series, which is the problem addressed in migrating BMS point history.

None of this is a criticism. For the purpose of operating plant, those properties are either neutral or positive. The mechanics of reading trend data out over the protocol are in BACnet data logging.

2. What a separate store adds

A historian, in the sense used here and defined more fully in what is a BMS data historian, is not a better trend log. It is a different thing with four properties trend logs structurally lack.

• Retention set by policy rather than by buffer size. Duration becomes a decision with a cost attached, as in the retention policy, not a side effect of an interval setting.
• One namespace across systems and sites. This is the capability that makes cross-system questions possible at all, and it depends on resolving the identity problem described in point naming and cross-system joins.
• Independence from the control system lifecycle. History survives a head-end replacement because it does not live in the head end.
• Query access for other tools. Reporting, analytics and the maintenance system can read it without anybody granting them access to the control network, which is the security argument in securing read-only access.

3. Side by side

4. The middle ground that is usually the right answer

The choice is routinely presented as either or, and in practice most estates land somewhere between, deliberately or by accident.

• Keep trend logs as the operating record and collect a subset centrally. Pick the points that feed reporting, compliance and the maintenance system, and leave the rest where they are. This keeps the central store small enough to be cheap and well understood.
• Use trend logs as the buffer for the central store. Reading logged records rather than live values makes the collection resilient to short outages, because the controller held the data while the link was down. This is the same principle as gateway store-and-forward, implemented one layer down.
• Export on demand for investigations. Viable, genuinely common, and the thing people claim is fine right up to the point where an investigation needs six systems and three years.
• Collect everything centrally and stop maintaining trends. Tempting and usually a mistake, because the trend log is what the person standing in front of the plant actually uses.

5. Fix the trend configuration first either way

Whichever direction you go, there is work on the trend logs that pays off immediately and costs nothing.

Most estates have logs configured years ago by whoever commissioned the system, with intervals and buffer sizes that were defaults rather than decisions. The result is a mixture of points logged far more often than anybody needs, points not logged at all, and a few critical points whose buffers hold a couple of days because somebody tightened the interval for a troubleshooting exercise and never put it back. Reviewing that against the register in the point dictionary is an afternoon of work that improves the operating picture whether or not you ever build a central store, and it also tells you the real volume you would be ingesting, which feeds storage sizing.

6. Mistakes on both sides of the argument

• Procuring a platform without a question it answers. A store with no consumer decays. Nobody notices when ingestion breaks, and the first real query lands on data with gaps nobody was watching.
• Assuming the trend window is what it says. Buffer sizes are per object and frequently inconsistent. Check the oldest record actually present on the points that matter rather than the configured intent.
• Treating the head end as a historian because it has a reports module. Some supervisory products genuinely do hold long history well. Many hold it in a form that is adequate for their own reports and difficult to query from anywhere else, which is a different thing.
• Building the store and leaving identity unresolved. A central store whose points cannot be tied to assets is a pile of numbered series, which is the failure mode addressed in point-to-asset mapping.

The idea to walk away with

Trend logs and historians are not competing implementations of the same idea. One is an operating instrument scoped to a system and bounded by a buffer; the other is an estate-wide record whose duration is a policy decision.

Decide between them with three real questions and two boundaries, duration and system scope. Expect the honest answer to be a subset collected centrally with trend logs left in place, and tidy the trend configuration first because that work is cheap and useful regardless of what you decide.

Final thoughts

The most informative check takes ten minutes. Pick your five most critical points and find the timestamp of the oldest record each trend log currently holds.

If those dates are further back than the questions you need to answer, you have a configuration task and no procurement. If they are a few days old on points that matter, you have just found something worth fixing this week, and the wider architecture question can wait until that is done.

Related reading: What is a BMS data historian, BACnet data logging, Storage sizing, Data retention policy, Migrating point history, SCADA historian integration.