Before Edge Calls Something Wrong

That is why Edge should not begin with an anomaly score. It should begin by asking whether the reading can be trusted.

Building data arrives with history attached. A value comes from a particular controller, over a particular network, at a particular time. It has a unit, a quality and a relationship to other points on the same piece of plant. Lose that context and even a sophisticated model can produce a very confident distraction.

Check the signal before the system

The first question is simple: did the value arrive as expected?

Edge looks at the health of the data path as well as the number at the end of it. Is the device online? Is the point updating? Has it flatlined? Are its units known? Did a field bus slow down, or did the gateway lose contact with a group of devices at once?

Those checks matter on BACnet networks. Some devices sit directly on BACnet/IP. Others are reached through slower MS/TP networks behind routers. Reading too aggressively can create the very communications problem the software is trying to diagnose, so the Edge Gateway adapts its polling to the response of each part of the network.

If the wider connection disappears, readings are buffered locally and replayed when it returns. A gap in the cloud record should not automatically become a story about a failed building.

Put the point back on the equipment

A trustworthy signal is still only one point.

Operators rarely fix a building by looking at a temperature in isolation. They need to know which fan-coil unit, air-handling unit or pump it belongs to, what that asset was being asked to do, and how the related valves, fans, modes and setpoints behaved at the same time.

This is where equipment mapping becomes important. Edge is designed to connect raw controller objects to a reviewable asset model rather than hide the original data. The mapping can be checked, corrected and improved as the building record develops.

That distinction is practical. If a valve is open and a room is still hot, the next question may be about flow, mode or plant availability. If the valve point is attached to the wrong asset, there is no useful diagnosis to make yet.

Prefer evidence over mystery scores

Edge combines deterministic checks — stale values, implausible combinations, missing updates and known relationships between points — with anomaly detection that can be enabled or disabled per project. The useful output is a finding an engineer can inspect, supported by the signals, asset context and recent behaviour beneath it.

That reviewable structure keeps anomaly detection practical. An engineer can see why something has been raised, inspect the contributing points and decide what the building needs next.

The order matters:

Check that the signal is current and correctly described. Confirm which asset and operating state it belongs to. Compare it with related points and recent behaviour. Assemble the evidence for an operator. Let the operator decide what happens next.

That last step is deliberate. Finding a likely fault is different from changing a building. Any control action needs its own authority, safety checks and readback.

Edge across our projects

Edge supports different operating briefs across our projects. Thirty High is a great example of the data density involved: more than 1,000 mechanical plant assets feeding a structured operator view. Point health, data integrity, assets, trends and anomaly findings work together so teams can move from an unusual reading to the surrounding system.

The value is a clear route from detection to engineering action.

The hard part of anomaly detection is not drawing attention to an unusual number. It is giving an engineer enough dependable context to decide whether the building is wrong, the data is wrong, or nothing needs changing at all.