Equipment inference
Once a building's points are classified, much of its equipment model
follows. src/baler/equip_inference.py works that out, and everything
it finds is a proposal with its evidence, for a person to confirm in
Mapping review. Nothing is asserted silently.
Equipment type from its point set
An equip with chilled water supply and return temperatures, a run status and a start/stop command is a chiller.
- The signatures are Cx's own expected-point templates
(
ontology/cx-expected-points.ttl): AHU, VAV, FCU, chiller, boiler and pump. Two more cover kinds Cx doesn't template: electrical meters and fans. - Each signature gets a score from two things: how many of its expected points the equip has (a required point counts double), and how much of the equip's point set the signature explains.
- For an equipment proposal, the model step lists the top three as candidates, marked points, with a reason such as "has 4 of 4 expected points (chilled water supply temperature, …)".
Cx's expected-point check. Suppose the ladder would auto-accept an equip (by memory, the model or a site rule) as a class whose required expected points are missing, such as an AHU with no fan status. That's suspicious, so it is vetoed and stays a proposal. The check runs only once every one of the equip's points is classified, because an unclassified point may be the missing one. In the measurement below, a looser threshold (80% classified) vetoed 6 correct answers on the mock hospital.
Relationships
python -m baler.autotag ends by proposing relationships, which appear in
the review page's Equipment relationships section:
- Grouping (
hasPoint). Points with no equipment are grouped by their topic's parent (a device or prefix group), and each group is proposed as one piece of equipment. Accepting creates the equipment and links its points. feeds. A VAV's discharge air temperature that tracks one AHU's supply air temperature suggests that AHU feeds it.- The test is Pearson's r over 5-minute means of the last 3 days.
- It proposes only when r ≥ 0.8 over at least 24 shared samples, and the best AHU beats the next by at least 0.1.
- Accepting writes
brick:feedsandbrick:isFedBy.
Accepted relationships are logged in record_edits. The API is
GET /ops/mapping/relationships (viewer) and
POST /ops/mapping/relationships/decide (operator).
Measured
On the mapping eval's mock hospital (88 pieces of equipment):
| Equipment: true class is the top candidate | Equipment exact, auto-accepted | |
|---|---|---|
| Rules only, before | 77.3% | 0% |
| Rules only, with point-set inference | 84.1% | 0% (still proposals) |
| With memory from seed 7 | n/a | 100%, 0 wrong (the Cx check vetoes nothing correct) |
With the true point classes, inference alone gets the exact class for
74 of 88 pieces of equipment and is never wrong. The other 14 come out
less specific. Six pumps come out as Pump rather than Chilled_Water_Pump
or Hot_Water_Pump, because their points are identical. Eight exhaust fans
come out as Fan rather than Exhaust_Fan, because a fan status and
command don't say exhaust. The label or a person settles those.
Not measured: feeds and grouping on real data. The mock hospital
has no VAV discharge temperatures, and its history is one reading per
point. Every point there is already on a piece of equipment. Unit tests
cover both with synthetic series and graphs: the right AHU is picked, a tie
proposes nothing, and too few samples propose nothing. Their first real
test is a site with history.