Point type definitions

[berkoben]

I'm in the process of trying to map brick to a live system and I'm having some difficulty determining what maps to what because the base point types are not defined anywhere. Ex:

I have a system (VAV) with:

• a schedule-based occupancy value (schedule_occ)
• an occupancy override value (from the button a person presses to say they're here) (occ_override)
• an effective occupancy that combines the two (effective_occ)

From Brick we have (VAV_ omitted for brevity): Occupancy_Status Temporary_Occupancy_Status Occupancy_Command Occupancy_Sensor Occupied_Command

I am assuming that the correct mapping is: schedule_occ:occupancy_status occ_override:temporary_occupancy_status effective_occ:Occupancy_command

But is is not clear anywhere what the difference is between a "Status", a "Command" and a "Sensor", so It's hard to know if this is correct.

Do these definitions exist somewhere? If so, could they be added to he source? If not, maybe we need a RFC to create them?

[berkoben]

For completeness. All of the direct subclasses of point I could find were:

Setpoint Alarm Command Status Sensor Resource Meter

Each of these requires a precise definition

[jbkoh]

You are right, documentation is 'the' necessary job that has been held for a while. I add my understanding used in the design but note that there is no official agreement on those yet. We can use this thread to finalize the definitions.

From other standards

ASHRAE dictionary

• Status: (1) indication of a device’s operating mode (ON or OFF). (2) state, position, or condition of an item.
• Alarm: Signal, either audible or visual, or both, that alerts an operator to an off-normal condition which requires some form of corrective action.
• Setpoint: point at which the desired temperature (°F [°C]) of the heated or cooled space is set.
• Sensor: device or instrument designed to detect and measure a variable.

Project Haystack

• Meter: Equip which meters usage of elec energy, thermal energy, gas, water or steam.
• Cmd: Classifies a point as an output, AO/BO, command, or actuator.

My thoughts for Brick

• You can think of Sensor and Status are points observing the world though Status is more abstracted or Equipment-related.
  E.g., Temperature Sensor observes temperature of physical target. Fault Status observes false of target Equipment.

• Setpoints and Commands are set by a human or a control system for control reference.

• Meter: I think we followed Haystack's definition for this. Somebody else can clarify this.

  • I 'personally' think it should be Equipment that includes multiple sensors, and just call Power Sensor instead of Power Meter but no agreement yet.

• Alarm: I was not certain with this too. I think it is a specific case (subclass) of Status.

• Resource: This is different from Points. We currently define it as : Physical resource or materials that are controlled by equipment and measured by points. An AHU controls resources such as water and air, to provide conditioned air to its terminal units

Occupancy-related

• Occupied Command is determined by control algorithms and referred by a VAV to determine its operations. Whether a person is in the room is unimportant for the value but it will be anyway referred by a VAV for its operations.
• Occupancy Sensor is a sensor observing occupancy. It purely observes occupancy at any time as a sensor whether it is an abstracted true/false value or an analog value of motion sensors. (I bet most people would use it for true/false value.)
• Occupancy Status is somewhat confusing. It's originated from Temporary Occupancy Status used by JonhsonControls (maybe in others' too.). It is a thermostat value indicating whether a tenant pushed corresponding button or not, which continues for two hours. So it is a value read from the thermostat indicating occupancy status temporarily, but it is not an Occupancy Sensor because not detecting occupancy.
  • My opinion is to remove Occupancy Status to reduce confusion.

Those are quick answers but I will initiate some formal definitions soon. Please share your thoughts too.

[jbkoh]

Forgot to answer to your specific systems:

From what I (probably the others too) have done:

• schedule_occ == Occupied_Command
• occ_override == Temporary Occupancy Status
• effective_occ: I have not seen this. This should be the Occupied_Command.

I would suggest (to Brick community)

• to develop Occupied_Command for schedule_occ. Maybe Scheduled_Occupied_Command?
• to use Occupancy_Override_Sensor instead of Temporary Occupancy Status.

[berkoben]

Given this information I would probably go with:

scheduled_occ : Scheduled_Occpuancy_Status occ_override : Temporary_Occupancy_status effective_occ: Occupancy_command | Occupancy_Status

I think I like to think of Command as a strict output designed to be consumed by another controller, or a piece of physical hardware. As a result I think I would prefer "status" than "Command" for the third value above, as it is only consumed by the controller. Occupancy_status is also a superclass of temporary... and scheduled... which makes logical sense.

[jbkoh]

I agree. I was too biased to vendor-given metadata that I had, but after reading the ASHRAE definitions (even though I posted it!), I feel we have to use Status.

A possible danger with introducing "scheduled" is that the term gives an impression of "future" values while Scheduled_Occupancy_Status is not related to the future at all but just the current status. I am fine with it, but would like to listen to you and the others. If the term is problematic, maybe "Base_Occupancy_Status"?

[berkoben]

Calendar_occupancy_Status better? The sctual variable name in ALC is "Schedule" I think in the depths of the bacnet object there is in-fact a schedule, but not sure as my investigation tool is currently down.

Also: Effective_Occupancy_Status probably makes sense for the one used by the control program. This mirrors what is already in place for temperature.

[jbkoh]

Sorry for the delayed response. I will finalize issues as many as possible today. In this thread:

Occupancy-related

1. I like Calendar_Occupancy_Status is better
2. Let's keep Temporary_Occupancy_Status
3. Let's introduce Effective_Occupancy_Status
4. Occupancy_Status is a generic occupancy status. 1.-3. are subclasses of Occupancy_Status

Basic Point Definitions

I propose following definitions:

1. Status: (1) indication of a device’s operating mode (ON or OFF). (2) state, position, or condition of an item. (adopted from ASHRAE dictionary)
2. Alarm: Signal, either audible or visual, or both, that alerts an operator to an off-normal condition which requires some form of corrective action.
3. Setpoint: point at which the desired property is set. (modified from ASHRAE dictionary)
4. Sensor: device or instrument designed to detect and measure a variable.
5. Command: output point that determines equipment's behavior directly and/or affects relevant operational points.

1.-4. are straightforward I think but it's a bit ambiguous to distinguish Command from Status. I tried to clarify with "output" but please suggest if any of you have better idea.

Etc.

1. Let's move Meter to Equipment. Is there any objection?

I will create RFCs for those items. Let me know any other opinions.

[bbalaji-ucsd]

A few thoughts:

1. I have seen the use of “schedule” in several BMSes. Would prefer using that over “calendar” which I’ve never seen used in practice.
2. I’d prefer use of “Occupancy_Command” over “Occupancy_Status”. From what I understand, command actually controls the set points of the HVAC zone, while status usually indicates status inferred from occupancy sensors. Status usually does not “control” other stuff.
3. We can introduce a separate “Schedule” class. For example: “Occupancy_Schedule” controls “Scheduled_Occupancy_Command”. Similar schedules are used all over the BMS and BACnet has it in it’s standard as Keith pointed out.
4. “Temporary Occupancy Status” actually is a misnomer. I’d prefer bringing in the “Interface” example here that Ben pointed out in the Lighting thread. Whenever an occupant uses this button, the “override” seems to be fitting as it does over-rule the existing schedule.

Regards, Bharath

On Wed, Sep 20, 2017 at 1:35 PM, Jason Beomkyu Koh <notifications@github.com

wrote:

Sorry for the delayed response. I will finalize issues as many as possible today. In this thread: Occupancy-related

1. I like Calendar_Occupancy_Status is better
2. Let's keep Temporary_Occupancy_Status
3. Let's introduce Effective_Occupancy_Status
4. Occupancy_Status is a generic occupancy status. 1.-3. are subclasses of Occupancy_Status

Basic Point Definitions

I propose following definitions:

1. Status: (1) indication of a device’s operating mode (ON or OFF). (2) state, position, or condition of an item. (adopted from ASHRAE dictionary)
2. Alarm: Signal, either audible or visual, or both, that alerts an operator to an off-normal condition which requires some form of corrective action.
3. Setpoint: point at which the desired property is set. (modified from ASHRAE dictionary)
4. Sensor: device or instrument designed to detect and measure a variable.
5. Command: output point that determines equipment's behavior directly and/or affects relevant operational points.

1.-4. are straightforward I think but it's a bit ambiguous to distinguish Command from Status. I tried to clarify with "output" but please suggest if any of you have better idea. Etc.

1. Let's move Meter to Equipment. Is there any objection?

I will create RFCs for those items. Let me know any other opinions.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BuildSysUniformMetadata/Brick/issues/32#issuecomment-330972987, or mute the thread https://github.com/notifications/unsubscribe-auth/ADFqQgASx3MB_U5nrcaRqYcrGu4thyLSks5skXcSgaJpZM4PVAOk .

[jbkoh]

Those suggestions generally make sense to me.

• let's stick to Scheduled_Occupied_Status (typo) Scheduled_Occupancy_Command.
• It's too early to introduce Schedule TagSet. One can issue another thread to discuss it. I think it's necessary though.
• The reason that we came down to Status was the ASHRAE definition. And input/output concepts are quite confusing when it comes to selecting vocabularies. Between Status and Command I think the difference is (strictly speaking):
  1. Status: when I observe the value, the value should be the actual current state of the behavior..
  2. Command: when I observe the value, it will be soon used for actual behavior.
  3. The difference is quite subtle. I think BACNet industry has not distinguished such concepts precisely. I however agree with Bharath that Occupied Command sounds better as it does not reflect the status of VAV directly but a control nob that we can control.
• Using Override Occupancy Command sounds better to me as well.

[jbkoh]

Closing this as it resulted in two RFCs in https://github.com/BuildSysUniformMetadata/Brick/issues/33 and https://github.com/BuildSysUniformMetadata/Brick/issues/34.