First, hello gentlemen.

I am working on an ontology for digital twin -real asset management. I am using a 2B$ hospital complex construction project in BIM environment as a lab to implement this.

My goas is to create a data structure that is compatible with the 3 legs of a stable digital twin: 1- geomertical data (Revit) 2- Computer assisted maintenance system environment (SQL server) 3- Building automation systems (in a hospital complex with many interlinked buildings, built a different times through different contracts, we have honeywell, siemens, etc).

So, I end up here. I notice something that I notice everywhere: there seems to be no convention about equipment and points relationships.

Long story short, here is an applied question:

I have a natural gas fired hot water boiler, then I have a hot water pipe, then a flowmeter, then a circulation pump.

I could arbitrarily tag the flowmeter control point as "hot-water-boiler_outflow", "pump_inflow" or even "flowmeter_reading".

Is there any convention about this?

Thanks!

Hi Richard,

We are actively working on new documentation for point conventions or patterns for Haystack 5 and expect that will be available soon.

Here is a mapping from your example to a Xeto spec that I think may apply:

• "flowmeter_reading": ph.points::WaterFlowSensor

This is an abstract spec, which specs indicating the direction of the flow of water could inherit from.

It might make sense we include specs indicating the direction of the flow of water in the ph.points library. I will bring this up during our Haystack Labs working group meeting this Wednesday, July 15.

Regarding the boiler semantics, Haystack 5 supports flat and nested data models. In other words the boiler semantics could be applied to a point entity like you showed in one of your examples.

-Rick

If you want to model a detailed topology of the hydronic system (or air/elec systems), then you use use the flow refs such as hotWaterRef, airRef, elecRef. These tags model the flow of energy/substances. So in your case probably something like this:

id: @boiler
---
id:  @flow-meter
hotWaterRef: @boiler
---
id:  @circ-pump
hotWaterRef: @flow-meter

You can model the individual pipes too, but that is typically beyond the level of details most people typically want or need.

Thank you gentlemen for the replies.

If I may bring up some important points to Rick, managing real assets for large infrastructures will typically require someone working with 3 separate databases built in the The Goldilocks Zone of Granularity. A granularity that is too fine makes the management too difficult. A granularity too coarse makes the management too arbitrary.

The 3 databases are: mapping, maintaining, monitoring. The endgame of managing is money, so the very first goal of these 3 databases is to tell us what costs what.

Here's some food for thoughts. If you can't think of managing something with paper, you won't succeed in managing it on a computer.

Think of paper plans. (Magic trick with Revit is to easily generate sets of plans focused on specific data segmentation). I want one big A1 paper plan per system, tagged with equipments that belongs to this system.

Think of paper file folders in a good old steel cabinet. One folder for every system. I want to file invoices and compile costs, work reports, pictures by system. I want a CMMS hierarchical ownership tree with assets tagged by system and by equipment, following the same structure. Multi-Root Forest model mathematically is the only way to enforce an injunctive mapping (where every asset maps to exactly one financial parent) and completely eliminate arbitrary cost splitting.

Even if multiple systems can be interconnected, each system needs to be segmented and represented as a root in the tree, so conventions will be needed.

Third leg: I want the monitoring to use the same tags and segmentation for systems and equipments when naming points. The goal is to make it easy to navigate from maps, to technical documents, to monitoring signals.

When I first started working on this with some consortium of engineers and architects, I noticed that different professionnals will organize that tree in different ways.

Example: I have a steam system connected to a heat exchanger to produce hot glycol in a separate loop for winter heating needs. In the hierarchical ownership tree, I have a steam system and a glycol system. Separated roots. The heat exchanger belongs to which system?

Followed philosophical discussions about energy flow, loads, sources, etc. I ended up with one clear convention: when one equipment is simultaneously connected to multiple systems, it belongs to the system it gives service to. This avoids reversing logics between cooling and heating.

In the case of the heat exchanger, if we shut down the heat exchanger, the steam system will carry on elsewhere, suppying sterilization, humidifiers and other various processes. But the glycol system will suffer. Therefore, the heat exchanger belongs to the glycol system.

Other example: a air handling unit is simultaneously connected to electrical supply, it has a cold water hydronic coil, it has ducts to a ventilation system, maybe some other coil (glycol, etc.). Using the same convention, the AHU is part of the ventilation system.

I ended up developing a set of conventions (there are many more) to manage all sorts of system configurations in piping, ducts and cable systems.

I believe that these conventions could be integrated into Building automation systems.

Let me know what you think of this!

Hi Richard,

I agree with you we need to look it from a practical way. As Brian writes use the flow refs. So what we do in our project is the following: To have a clear relationship we using the principle of Measurement and Control engineering which is common used input-control-output in case of energy: Utility →Production →Distribution→ Users Utility import of energy to service the Production Production service the Distribution Distribution service the Users. The equipment belong where it service to as you mention the heatexchanger is a part of the glycol system. The steamside belong to the steamboiler and the gaspipe is feeding the steamboiler. In this case the userside wil have an equipmentRef to that Heat Exchanger also the flowmeter,sensor,pumps ect. The Heat Exchanger wil have a BoilerRef and the SteamBoiler should get an utilityRef.

The problem is that everybody has a different view on this and it also depends on the job which a person has and what is the goal(energy usage or something else). I think we are in the transition from using proces coding to tagging which needs a total different way of thinking.

There's a lot of good thoughts here, and I'd like to throw in a few notes as this is closely related to the general problem where development of the Systems section of the ontology is stalled (or at least where I'm mentally stalled).

At the low level, which has existed in haystack for a long time, you have refs that are intrinsically tied to the medium being transferred, either nominally (like elecRef or waterRef) or implicitly (like submeterOf). These relationships are always 1 child & 1 parent, and allow for pretty explicit mapping of very detailed flow of water, air, electricity, and so on.

At the higher level, systems were introduced to encapsulate the kind of logical relationships you're talking about. The initial decision was to allow equipment to be co-members of different systems via systemRef as a multi-ref. So for instance a chiller would be systemRef: [ @ChilledWaterSystem, @CondenserWaterSystem], and the same could follow for a Boiler that maybe belongs to a Hot Water System and a Natural Gas System and so on.

Currently, Haystack Labs, one of the working groups, when we discuss this topic circles around a few concepts that are somewhat in tension with each other:

1. How to balance entities being organized into systems when they are a producer in one, and a consumer in another? How to identify which system they are serve which purpose?
2. Where to other organizational constructs like loops belong in this model?
3. Should the systemRef tag be exploded out by system type? I.e., instead of all systemRefs being piled into one list of refs, what if we uniquely identified refs as chilledWaterSystemRef, condenserWaterSystemRef, elecSystemRef, etc. etc.

There are a lot of things to consider in all directions, and each come with trade offs. For instance, on #1 we could identify equipment as a producer/consumer based off of some equipProcess tag that the equip invokes which infers some input/output relationship. That might work for a Chiller (condenser water in, chilled water out), but what about VRF systems where you might have Primary & Secondary Condenser Water on a Heat Exchanger, and so on.

I think the biggest problem boils down to: how do we neatly cover the way groups of equipment relate to each other at a high level, without having to model the detailed energy/fluid flow between each individual asset.

Mike Melillo, I would have a recommendation to "mentally unstall" the systems types.

In my case, I started by looking at every legal intervention required in the lifespan of a system. This will often determine obligatory archetypes.

For example, Florida Boiler Safety Act, https://florida.public.law/statutes/fla._stat._554.108, you find the following 3 archetypes: Power boilers and high pressure, high temperature water boilers Low pressure steam or vapor heating boilers Hot water heating boilers and hot water supply boilers

When creating tags to make an inventory and to map assets, it's important to focus on what is important to know.

If I just make a list of "boiler 1, boiler 2, boiler 3..." i'm stuck, because I'll need a more specific info from somewhere else in a database.

If I make a list of " high pressure boiler painted in blue 1, high pressure boiler painted in blue 2, high pressure boiler painted in green 1" I introduce an unnessary detail that shifts the tag incrementation.

To the sweet spot for boiler tags in inventory and mapping in Florida would be "high pressure boiler 1, high pressure boiler 2, high pressure boiler 3".

The system types are natural derivatives of the equipments. There will be "high pressure steam system" and "low pressure steam system" as well as "hot water heating system".

In dealing with equipments that could be co-members of different systems, it's very possible to manage such a database for loads/sources and monitoring purposes. But there needs to be some sort of "financial - functionnal - legal" convention to define a very specific membership status with one equipment to one system. Just like a paper folder can't be stored in two drawers simultaneously. Splitting equipment's costs between various systems seems a very good way to make every performance indicator arbitrary.

I do have conventions to propose that could clearly answer your questions #1, #2 and #3. It gives a clear answer to the case you mention with VRF systems.

That would be a long post, but I will post that "proposed standard" if you gentlemen are interested in looking into it.

Every asset must belong to exactly one system — the system it provides service to This eliminates arbitrary dual membership and resolves producer/consumer ambiguity without needing to model every flow path.

From our standard:

“When one equipment is simultaneously connected to multiple systems, it belongs to the system it gives service to.”

This single rule removes the need for multi‑refs and prevents cost‑splitting, which is critical for CMMS, budgeting, and lifecycle reporting.

1. System segmentation must be driven by legal, functional, and maintenance archetypes.

Instead of starting from flows or ontology abstractions, we start from the interventions required over the lifespan of the system.

The VRF systems case is a good one, as it often create producer/consumer reversals depending on mode, season, or loop configuration. Instead of trying to encode all flow directions, we apply the same service‑based rule:

Identify which subsystem loses its intended function if the equipment is removed. Assign the equipment to that system. Represent other connections as interfaces, not membership.

I would have a VRF system drawer. In that drawer, I'd have folders for every equipment of the system: compressors, condensers, selector boxes, indoor fan coil units, etc. If there's a heat exchanger to another water cooling system with water towers, the cooling water system is another separate system with it's own drawer. The heat exchanger would be considered part of the VRF system. If it was removed, the cooling water system could still manage cooling loads from other sources, but the VRF system would overheat.

This keeps the ontology simple, stable, and compatible with CMMS, BIM, and BAS naming.

If useful, I can share the full proposed standard It includes:

System separation conventions Rules for small vs. large systems Equipment/component classification Manual isolation device boundaries Multi‑system equipment resolution hierarchy Coding structure for piping, duct, cable, façade, and partition systems

It was designed specifically to unify BIM, CMMS, and BAS under a single segmentation logic, which seems aligned with the goals you describe.

If the working group is interested, I can post the full draft.

Working with systems is for me a little bit unlogic. If I have a chiller then I know it is a chilledwatersystem in 95% of the case the producing equipment is telling what kind of system it is. What i think about is to have a subEquipment. Just like with meters sitemeter submeter.

Today you see more and more equipment which have communication like pump s but also EPICV (Electronic Pressure Independent Control Valves which are a part of of boiler system of chillerwater heatpump system but also from VAV boxes or Chilled ceiling. It should be more logic to have this:

equip; chiller

subequip; evappump
subequip: condenspump

or

equip: vav

subequip: epivc
subequip: lightmodule 
subequip: lorasensor 

of course you can use equipRef

We are also struggling with that. My Engineers say why is there no room or zone in the tree like site floor zone or room vav or fcu or light.

Hi Frank,

The reason to label each system is that large campuses and high rise buildings often have more than one chilledwatersystem, multiple domestic water taps, etc.

In large complexes, systems often are shared over multiple buildings, linked with tunnels. Sometimes though, multiple systems of the same nature are completely independent. Often, these systems have different histories, have been built at different times in the evolution of a large site, as old buildings are demolished, old buildings are renovated and new buildings are added.

It's possible to have 5 chillers on one site and it's important to know that chiller 1 and 2 are givig service to chilledwatersystem 1, then chiller 3-4-5 are giving service to chilledwatersystem 2.

Each system needs it's own mapping, it's own file drawer with plans, inspection program, finance and technical documentation.

I understand that this issue is relevant for large complexes where it's possible to have multiple similar systems. But in the context of thinking of a "standard", the worst case has to be the foundation for a logic that can be applied everywhere.

Richard,

So the in the chilledwaterplant chiller 1 and 2 are feeding chilledwatersystem1 and 3-4-5 are feeding chilledwatersystem 2 in that case it will logic to do that. If you want to make a standard then you have als to this with chillerplant which is feeding 1 chilledwatersystem. So it will always acombination of these two. sound for me logical.