Local loop verify #8
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,120 @@ | ||
| # Local Loop Performance Verification Library Items | ||
|
|
||
| ---- | ||
|
|
||
| ## Local Loop Performance Verification - Set Point Tracking | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks the set point tracking ability of local control loops. | ||
|
|
||
| ### Verification logic | ||
|
|
||
| With a threshold of 5% of abs(set_point) (if the set point is 0, then the threshold is default to be 0.01), if the number of samples of which the error is larger than this threshold is beyond 5% of number of all samples, then this verification fails; Otherwise, it passes. | ||
|
|
||
| ### Data requirements | ||
|
|
||
| - feedback_sensor: feedback sensor reading of the subject to be controlled towards a set point | ||
| - set_point: set point value | ||
|
|
||
|
|
||
| ## Local Loop Performance Verification - Set Point Unmet Hours | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks the set point tracking ability of local control loops. | ||
|
|
||
| ### Verification logic | ||
|
|
||
| Instead of checking the number of samples among the whole data set for which the set points are not met, this verification checks the total accumulated time that the set points are not met within a threshold of 5% of abs(set_point) (if the set point is 0, then the threshold is default to be 0.01). | ||
|
|
||
| If the accumulated time of unmet set point is beyond 5% of the whole duration the data covers, then this verification fails; otherwise, it passes. | ||
|
|
||
| ### Data requirements | ||
|
|
||
| - feedback_sensor: feedback sensor reading of the subject to be controlled towards a set point | ||
| - set_point: set point value | ||
|
|
||
| ## Local Loop Performance Verification - Direct Acting Loop Actuator Maximum Saturation | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks that a direct acting control loop would saturate its actuator to maximum when the error is consistently above the set point [^1]. | ||
|
|
||
| ### Verification logic | ||
|
|
||
| If the sensed data values are consistently above its set point, and after a default of 1 hour, the control command is still not saturated to maximum, then the verification fails; Otherwise, it passes. | ||
|
|
||
| ### Data requirements | ||
|
|
||
| - feedback_sensor: feedback sensor reading of the subject to be controlled towards a set point | ||
| - set_point: set point value | ||
| - cmd : control command | ||
| - cmd_max: control command range maximum value | ||
|
|
||
| ## Local Loop Performance Verification - Direct Acting Loop Actuator Minimum Saturation | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks that a direct acting control loop would saturate its actuator to minimum when the error is consistently below the set point [^1]. | ||
|
|
||
| ### Verification logic | ||
|
|
||
| If the sensed data values are consistently below its set point, and after a default of 1 hour, the control command is still not saturated to minimum, then the verification fails; Otherwise, it passes. | ||
|
|
||
| ### Data requirements | ||
|
|
||
| - feedback_sensor: feedback sensor reading of the subject to be controlled towards a set point | ||
| - set_point: set point value | ||
| - cmd : control command | ||
| - cmd_min: control command range minimum value | ||
|
|
||
| ## Local Loop Performance Verification - Reverse Acting Loop Actuator Maximum Saturation | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks that a reverse acting control loop would saturate its actuator to maximum when the error is consistently below the set point [^1]. | ||
|
|
||
| ### Verification logic | ||
|
|
||
| If the sensed data values are consistently below its set point, and after a default of 1 hour, the control command is still not saturated to maximum, then the verification fails; Otherwise, it passes. | ||
|
|
||
| ### Data requirements | ||
|
|
||
| - feedback_sensor: feedback sensor reading of the subject to be controlled towards a set point | ||
| - set_point: set point value | ||
| - cmd : control command | ||
| - cmd_max: control command range maximum value | ||
|
|
||
| ## Local Loop Performance Verification - Reverse Acting Loop Actuator Minimum Saturation | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks that a reverse acting control loop would saturate its actuator to minimum when the error is consistently above the set point [^1]. | ||
|
|
||
| ### Verification logic | ||
|
|
||
| If the sensed data values are consistently above its set point, and after a default of 1 hour, the control command is still not saturated to minimum, then the verification fails; Otherwise, it passes. | ||
|
|
||
| ### Data requirements | ||
|
|
||
| - feedback_sensor: feedback sensor reading of the subject to be controlled towards a set point | ||
| - set_point: set point value | ||
| - cmd : control command | ||
| - cmd_min: control command range minimum value | ||
|
|
||
| <!-- ## Local Loop Performance Verification - Loop Activation Hunting | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks if a loop has hunting behavior in terms of frequently activate and deactivate its actuator. --> | ||
|
|
||
| ## Local Loop Performance Verification - Actuator Rate of Change | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks if a local loop actuator has dramatic change of its actuating command. This verification is implemented as instructed by ASHRAE Guideline 36 2021 Section 5.1.9 in Verification Item `G36OutputChangeRateLimit`. | ||
|
|
||
|
|
||
|
|
||
| [^1]: Lei, Xuechen, Yan Chen, Mario Bergés, and Burcu Akinci. "Formalized control logic fault definition with ontological reasoning for air handling units." Automation in Construction 129 (2021): 103781. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,63 @@ | ||
| """ | ||
| ## Local Loop Performance Verification - Direct Acting Loop Actuator Maximum Saturation | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks that a direct acting control loop would saturate its actuator to maximum when the error is consistently above the set point. | ||
|
|
||
| ### Verification logic | ||
|
|
||
| If the sensed data values are consistently above its set point, and after a default of 1 hour, the control command is still not saturated to maximum, then the verification fails; Otherwise, it passes. | ||
|
|
||
| ### Data requirements | ||
|
|
||
| - feedback_sensor: feedback sensor reading of the subject to be controlled towards a set point | ||
| - set_point: set point value | ||
| - cmd: control command | ||
| - cmd_max: control command range maximum value | ||
|
|
||
| """ | ||
|
|
||
| import pandas as pd | ||
| from checklib import RuleCheckBase | ||
|
|
||
|
|
||
| class LocalLoopSaturationDirectActingMax(RuleCheckBase): | ||
| points = ["feedback_sensor", "set_point", "cmd", "cmd_max"] | ||
|
|
||
| def saturation_flag(self, t): | ||
| if 0 <= t["cmd_max"] - t["cmd"] <= 0.01: | ||
| return True | ||
| else: | ||
| return False | ||
|
|
||
| def err_flag(self, t): | ||
| if t["feedback_sensor"] > t["set_point"]: | ||
|
There was a problem hiding this comment. Same comment as above for the command. I doubt it but still wanted to raise the question in case you think that it might be an issue. There was a problem hiding this comment. To me this is a different issue from the comment earlier. Because this is a direct acting controller, then saturating towards maximum is the expected behavior when the sensor reading is constantly above the set point, not the other way around. |
||
| return True | ||
| else: | ||
| return False | ||
|
|
||
| def verify(self): | ||
| self.saturation = self.df.apply(lambda t: self.saturation_flag(t), axis=1) | ||
| self.err = self.df.apply(lambda t: self.err_flag(t), axis=1) | ||
| self.result = pd.Series(index=self.df.index) | ||
| err_start_time = None | ||
| err_time = 0 | ||
| for cur_time, cur in self.df.iterrows(): | ||
| if self.err.loc[cur_time]: | ||
| if err_start_time is None: | ||
| err_start_time = cur_time | ||
| else: | ||
| err_time = ( | ||
| cur_time - err_start_time | ||
| ).total_seconds() / 3600 # in hours | ||
| else: # reset | ||
| err_start_time = None | ||
| err_time = 0 | ||
|
|
||
| if err_time > 1 and (not self.saturation.loc[cur_time]): | ||
|
There was a problem hiding this comment. I use > 1 to make it a tiny bit more difficult to fail |
||
| result_flag = False | ||
| else: | ||
| result_flag = True | ||
|
|
||
| self.result.loc[cur_time] = result_flag | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,63 @@ | ||
| """ | ||
| ## Local Loop Performance Verification - Direct Acting Loop Actuator Minimum Saturation | ||
|
|
||
| ### Description | ||
|
|
||
| This verification checks that a direct acting control loop would saturate its actuator to minimum when the error is consistently below the set point. | ||
|
|
||
| ### Verification logic | ||
|
|
||
| If the sensed data values are consistently below its set point, and after a default of 1 hour, the control command is still not saturated to minimum, then the verification fails; Otherwise, it passes. | ||
|
|
||
| ### Data requirements | ||
|
|
||
| - feedback_sensor: feedback sensor reading of the subject to be controlled towards a set point | ||
| - set_point: set point value | ||
| - cmd: control command | ||
| - cmd_min: control command range minimum value | ||
|
|
||
| """ | ||
|
|
||
| import pandas as pd | ||
| from checklib import RuleCheckBase | ||
|
|
||
|
|
||
| class LocalLoopSaturationDirectActingMin(RuleCheckBase): | ||
|
There was a problem hiding this comment. Would it make sense to have only one verification that would handle min/max? The logic is essentially the same. There was a problem hiding this comment. similar to above, I think min and max are for sensor reading on two sides of the set points separately. |
||
| points = ["feedback_sensor", "set_point", "cmd", "cmd_min"] | ||
|
|
||
| def saturation_flag(self, t): | ||
| if 0 <= t["cmd"] - t["cmd_min"] <= 0.01: | ||
| return True | ||
| else: | ||
| return False | ||
|
|
||
| def err_flag(self, t): | ||
| if t["feedback_sensor"] < t["set_point"]: | ||
| return True | ||
| else: | ||
| return False | ||
|
|
||
| def verify(self): | ||
| self.saturation = self.df.apply(lambda t: self.saturation_flag(t), axis=1) | ||
| self.err = self.df.apply(lambda t: self.err_flag(t), axis=1) | ||
| self.result = pd.Series(index=self.df.index) | ||
| err_start_time = None | ||
| err_time = 0 | ||
| for cur_time, cur in self.df.iterrows(): | ||
| if self.err.loc[cur_time]: | ||
| if err_start_time is None: | ||
| err_start_time = cur_time | ||
| else: | ||
| err_time = ( | ||
| cur_time - err_start_time | ||
| ).total_seconds() / 3600 # in hours | ||
| else: # reset | ||
| err_start_time = None | ||
| err_time = 0 | ||
|
|
||
| if err_time > 1 and (not self.saturation.loc[cur_time]): | ||
| result_flag = False | ||
| else: | ||
| result_flag = True | ||
|
|
||
| self.result.loc[cur_time] = result_flag | ||
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the
0.01be a "user-input" with a default value? Similarly to how we handle tolerances.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any circumstances where the command might be negative for some reason? In other words should we use
abs(t["cmd_max"] - t["cmd"])?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for 1), my intention is to require as little user inputs / config as possible, so that 0.01 is used. We can certainly change it to a parameter later;
for 2), if it is negative, I would prefer to fail the verification or raise an error. For now, if it is negative, then this would be considered "not saturated", so it has a larger chance of reporting fail than pass.