#878 equipFunction and process suggestions

Mike Melillo Wed 23 Dec 2020

Edit: Revisions for clarity. After re-reading my notes here, I think what I'm ultimately suggesting is some sort of "equipFunction" and "process" reciprocalOf relationship, which is more than what I've put together as of yet. If anyone thinks there's something worth exploring more of here, I welcome the input.

I want to make some suggestions to flesh out the equipFunction and process defs more. The end-goal is to have them better describe the whole of an equip's sequence of operations when properly applied.

The major issue I run into right now is that these defs only describe the phenomenon affected and not the quantity. When drawing inferences between equipment that is related to another one's function or has a similar function, both the phenomenon and the quantity are crucial. I also think the verbiage of how several equipFunctions and processes are currently written lend themselves to my point. I have a few pasted below with my general summary statement of what an equipFunction or process actually is. However, to avoid needing to make process a subtype of choice as well, I think several processes can be reciprocalOf the same equipFunction -- I don't know if reciprocalOf is really the right def to apply though. Basically an equip can achieve the equipFunction cools: air-temp through several different processes (chilledWaterCooling, airCooling, dxCooling, etc) ... so having some relationship between those defs would allow making deeper inferences into what equipment is doing and how it is doing it.

conveys	
Equipment conveys a substance or phenomenon

cools	
Equipment removes heat from a substance

dehumidifies	
Equipment removes moisture from air to decrease humidity

equipFunction
Equipment "equipFunction"s upon a "phenomenon"s "quantity"

airCooling	
Cooling by dissipating heat into the surrounding air

chilledWaterCooling	
Cooling using transfer of heat to chilled water

process
"process" modifies "quantity" of target "phenomenon"

There are some exceptions, convey is the most straightforward one, although I suppose that could be overcome just by saying "elec-circuit conveys elec-power", but that feels like short-selling the whole thing. I'm not sure what to do in that instance.

Returning to the main point, I think the defs for all equipFunctions and processes should be modified like such:

def: cools
doc: Equipment removes heat from a substance
is: equipFunction
lib: phIoT
of: substance-quantity

def: chilledWaterCooling
doc: Cooling using transfer of heat to chilled water
is: coolingProcessType, chilled-water-input
lib: phIoT

Additionally, there should be a "twin" process that pairs with every equipFunction. The ideal scenario is that every equip could fully describe how its children points relate to its operation by having an equipFunction and process that somehow would relate to the points it contains. Take the following example, note flowProcess would be a child of choice, and damperModulation would be a child of an imaginary "flowProcessType" which is itself a child of process like coolingProcessType.

{id: @vav1, coolingProcess: airCooling, coolingOnly, cools: air-temp, regulates: air-flow, flowProcess: damperModulation}
{id: @sensor1, equipRef: @vav1, zone, air, temp, sensor}
{id: @sensor2, equipRef: @vav1, zone, air, temp, sp}
{id: @sensor3, equipRef: @vav1, zone, air, humidity}
{id: @sensor4, equipRef: @vav1, discharge, air, damper, cmd}
{id: @sensor5, equipRef: @vav1, discharge, air, flow, sensor}
{id: @sensor6, equipRef: @vav1, effective, discharge, air, flow sp}

If my interest is looking at issues on this VAV box, the current model is no issue, but if my desire is to find things related to this equipment's temperature or flow control processes, I have an issue. For instance, if I want to relate something that occurs between this vav box's Zone Temp & Zone Setpoint, I have to do some extra lifting to figure out that the only points I want to find on the related AHU are air-temp points, otherwise I end up with all form of sensors dealing with pressure, humidity, and who knows what else.

If my functions and processes already scope down to the phenomenon and quantity, it's a much more straightforward lift inferring what are the related up or downstream points (take the reverse example, I find an AHU problem and want to know which zones are affected in what way). I also think this has interesting implications for additional defs that can play together to fully describe an equips sequence of operations. If people are interested in this sort of idea, I could take a stab at fully fleshing out what I think process and equipFunction would look like.

Brian Frank Mon 4 Jan

These are good thoughts, thanks for your comments.

I am not sure the current design is quite right, because there definitely seems like there should be more of an ontological relationship between equipFunction and process. They are very close. What core ideas we are trying to capture is "what" and "how". For example an AHU cools air (what) using a process such as chilledWaterCooling (how). Or a boiler heats water (what) using a process such as fuelOilHeating (how).

But I think your core suggestion was along these lines:

// currently ahu
cools: ^air

// your suggestion
cools: ^air-temp

But by definition heats and cools is a process effecting temp. If anything we would want to move that into the equipFunction itself using some new association:

def: ^cools
is: ^equipFunction
of: ^substance
affectsQuantity: ^temp
doc: "Equipment removes heat from a substance."

Here I've added a tag named "affectsQuantity" to illustrate (but I'm not sure what we would call that). Both cool and heat affect temp. And dehumidifies and humidifies would affect humidity. However I'm not sure how else we might apply that. I guess you could say ventilates affects airQuality (which is the supertype of co, co2, pm10, pm25, and tvoc).

I'm almost thinking that maybe we should use the "good name" process for what is currently equipFunction.

Other thoughts?

Mike Melillo Mon 4 Jan

Thanks for the feedback, and yes regarding the core suggestion. I'm not sure you mean by "good name" process.

But taking the idea of a new association a bit further, I think there should be something like affectsQuantity and processUsed (using this for discussion's sake) to fully describe an equipFunction. My basic argument being an equipFunction is fully described when you can look at any implementation and fill in these blanks:

equipFunction: Performs this {{processUsed}} which modifies this 
{{quantity}} of this {{phenomenon}} using this {{input}}

Input would have to be inferred by the process. And the trick then is how to implement an equipProcess and associate it to the implemented processUsed. The resulting problem I can't wrap my head around is how to reshape the cools def so that when implemented it provides an association to say, a chilledWaterCooling process.

def: ^cools
is: ^equipFunction
of: ^substance
affectsQuantity: ^temp
processUsed: ^process
doc: "Equipment removes heat from a substance."

Implemented, that just lets me know my equipFunction requires some kind of process. Actually getting to the next step would require equipFunction being a choice of: ^substance-^process which sounds... super clunky? I'm not sure.

def: ^cools
is: ^equipFunction
of: ^substance-^process
affectsQuantity: ^temp
doc: "Equipment removes heat from a substance."
equip
ahu
cools: air-chilledWaterCooling

At the end of the day it's just another conjunct. Maybe it wouldn't feel as rough if the process name was leaner and I'm getting too caught up in that.

Curious to hear more though. I think this being fully fleshed out leads to a lot of interesting inference based applications.

Mike Melillo Yesterday

Okay, back for another round... been playing with this idea and a few different structures in demo and on the back end of a few projects, going to add the latest round of thoughts.

equipFunction as the top level choice is the start of most problems I'm running into. So, with this round equipFunction is moved under the process def I suggest below. Additionally several current equipFunctions get moved up to that process level.

Put another way, some processes do more than influence a single phenomenon via mechanical or electrical action. These processes typically involve some kind of thermodynamic energy transfer. I'm suggesting the following structure to model them.

Also, defining these processes fully at implementation is too cumbersome. It is more effective to define each possibility within the ontology (within reason), and also maintain an extensible structure so custom applications do not have to break the mold.

The fully defined defs further below would simply be applied as marker tags to the equips that implement that process. This should allow for the removal of the current process subtypes (everything in coolingProcessType and heatingProcessType).

Additionally, these defs will define the input, output, quantity affected, and the direction that quantity flows.

def:^process
doc:"Industrial or HVAC Process"
is:[^entity]

def:^processSubject
doc:"The quantity directly altered by some thermodynamic process or control strategy."
is:[^choice]
of:^quantity

def:^ioProcess
is:[^process,^input,^output]

def:^heatTransfer
is:[^ioProcess]
processSubject:^temp


The above tags model the top level structure for a process which always output some phenomenon and affected quantity. In the case of heatTransfer we require both an input and an output because the heat has to flow from somewhere to somewhere else. From here a few things have to be done on some sort of convention.

The next tier of defs specifically calls out the output of that particular instance of the process. The next tier down defines the input.

This basically means the fully qualified process name is inputToOutputProcess, e.g. airToAirCooling indicating there is a thermodynamic flow from this entity to that entity (positive or negative).

It might be possible to make this less bloated by removing defs that call out the direction of heat or energy transfer (e.g. heatTransfer vs. heating + cooling)... not sure though.

The next set takes heatTransfer and then cooling to (most of) its logical conclusions.

def:^cooling
doc:"Thermodynamic process where heat flows from the output to the input."
is:[^heatTransfer]

def:^heating
doc:"Thermodynamic process where heat flows from the input to the output."
is:[^heatTransfer]

----

def:^airCooling
is:[^cooling,^air-output]

def:^airToAirCooling
is:[^airCooling,^air-input]

def:^chwToAirCooling
is:[^airCooling,^chilled-water-input]

----

def:^cwCooling
is[^cooling, ^condenser-water-output]

def:^airToCwCooling
is:[^cwCooling, ^air-input]

def:^refrigToCwCooling
is[^cwCooling, ^refrig-input]

----

def:^chwCooling
is:[^cooling,^chilled-water-output]

def:^cwToChwCooling
is:[^chwCooling,^condenser-water-input]

def:^refrigToChwCooling
is:[^chwCooling,^refrig-input]

----

def:^refrigCooling
is:[^cooling,^refrig-output]

def:^airToRefrigCooling
is:[^refrigCooling,^air-input]

def:^cwToRefrigCooling
is:[^refrigCooling,^condenser-water-input]

From there heating builds up pretty similarly. I put some work into humidityControl but not totally happy yet, but I'd like to hear what other people think.

Login or Signup to reply.