|
|
Post by lucashorigan on Mar 18, 2024 14:09:23 GMT
The below recommendations are made for the document DSP0268 Version 2023.1 or Redfish Data Model Specification:
1. The Control v1.3 resource currently does not have any Enable/Disable property. A True/False property for turning a control point on and off would be beneficial for organization. A Control point such as a dew sensor with its setpoint may need to be disabled by the user. If something along the lines of:
“SetPoint”: <my-setpoint-variable>,
“TurnOn”: <True-False>
2. The Pump v1.0 could use an Emergency Shut Off property. There are multiple alarm cases in the CDU that can shut off the pump for several reasons. If a True/False kind of property could be added to the pump for this, it would be useful for organization.
3. The Pump v1.0 could use control properties such as PID related variables, Kp, Ki, Kd, etc or a place to source a control related to the pump to keep where changes can be made obvious to the end user
Please let me know if the above should be broken into separate threads for each point. Thanks.
EDIT: Removed an incorrect request made at number 4.
|
|
|
|
Post by jautor on Mar 18, 2024 21:08:26 GMT
The below recommendations are made for the document DSP0268 Version 2023.1 or Redfish Data Model Specification: 1. The Control v1.3 resource currently does not have any Enable/Disable property. A True/False property for turning a control point on and off would be beneficial for organization. A Control point such as a dew sensor with its setpoint may need to be disabled by the user. If something along the lines of: “SetPoint”: <my-setpoint-variable>, “TurnOn”: <True-False> There is support for enable/disable of a Control - it's handled by the ControlMode property, but not a boolean, as that single property handles manual/automatic/user-override modes as well as "Disabled" with a single property. We combined those so that it was clear that the "state" of the control was known from a single property instead of several... Let us know if there's some description text we should add there to make it more obvious (I'm guessing it blended in with several other properties that start with "Control...") Are you looking for the "alert" that the Emergency Shut Off has been used/triggered, or are you looking for the mechanism to initiate an emergency shut off? For the "alert", you can use a combination of Status/Health to show a "Critical" Health of the resource, and placing a message in Status/Conditions to explain what has triggered that case. We have not defined a standard message for "Emergency Shut Down" - but that clearly is something that could be used across the industry, so we'd certainly take a look at any suggestion there to add to a Message Registry (probably belongs in both the Power and Environmental message registries). If you want to actually initiate an emergency shut down, I'd probably suggest that it would be best implemented as an Action, with the results shown in the Status/Conditions. In the Control schema there is a ControlLoop object that contains the PID variables. So any Control surfaced to a pump has that capability. But as currently defined (and we didn't expose a lot of Control instances - deferring those until folks ask for them and/or provide feedback like this!), those properties aren't copied into the Control excerpt that gets shown in the functional resource (like Pump) where the Control is actually used. I think for this case we could either add the ControlLoop to the existing excerpt, or create a new excerpt specifically to use when the PID information is expected to be surfaced to the user (and probably read-write). I would assume that would be a new PumpSpeedControl in Pump, which would show the SetPoint, OperatingMode, and then the PID components as ControlLoop. So something like this: {
"PumpSpeedControl": {
"SetPoint": 47,
"OperatingMode": "Automatic",
"ControlLoop": {
"Proportional": 3,
"Integral": 1,
"Differential": 9
}
}
And we'll need to discuss that property name - because I would normally say that the units (Percent) need to be in the name, but since we already have PumpSpeedPercent naming this control as PumpSpeedControlPercent may be unnecessary? Maybe just SpeedControlPercent as we're in the Pump resource. (and I remember now that we named it PumpSpeedPercent because SpeedPercent didn't feel like enough context)
Jeff
|
|
|
|
Post by lucashorigan on Mar 20, 2024 15:14:22 GMT
The below recommendations are made for the document DSP0268 Version 2023.1 or Redfish Data Model Specification: 1. The Control v1.3 resource currently does not have any Enable/Disable property. A True/False property for turning a control point on and off would be beneficial for organization. A Control point such as a dew sensor with its setpoint may need to be disabled by the user. If something along the lines of: “SetPoint”: <my-setpoint-variable>, “TurnOn”: <True-False> You are correct, this is exactly what I am seeking out. So I will drop this point. Are you looking for the "alert" that the Emergency Shut Off has been used/triggered, or are you looking for the mechanism to initiate an emergency shut off?
For the "alert", you can use a combination of Status/Health to show a "Critical" Health of the resource, and placing a message in Status/Conditions to explain what has triggered that case. We have not defined a standard message for "Emergency Shut Down" - but that clearly is something that could be used across the industry, so we'd certainly take a look at any suggestion there to add to a Message Registry (probably belongs in both the Power and Environmental message registries).
If you want to actually initiate an emergency shut down, I'd probably suggest that it would be best implemented as an Action, with the results shown in the Status/Conditions.So to understand this correctly, an action can do a multi-step process following a POST command? i.e the Action "EmergencyStop" could be posted to the Pump resource, which will set PumpSpeedPercent to 0 and give a Condition that states the pump had an emergency stop. In the Control schema there is a ControlLoop object that contains the PID variables. So any Control surfaced to a pump has that capability. But as currently defined (and we didn't expose a lot of Control instances - deferring those until folks ask for them and/or provide feedback like this!), those properties aren't copied into the Control excerpt that gets shown in the functional resource (like Pump) where the Control is actually used.
I think for this case we could either add the ControlLoop to the existing excerpt, or create a new excerpt specifically to use when the PID information is expected to be surfaced to the user (and probably read-write).
I would assume that would be a new PumpSpeedControl in Pump, which would show the SetPoint, OperatingMode, and then the PID components as ControlLoop. So something like this:Exposing the ControlLoop to the Pump resource sounds good. As your below example shows, just having a place to display the PID values in Pump will be great. Could there also be a place to write the URI associated with the ControlLoop excerpt to source it back to the Controls section of the Schema? Would it be proper to just drop an @odata.id in the excerpt as below or is that reserved for Collection types only? {
"PumpSpeedControl": {
"SetPoint": 47,
"OperatingMode": "Automatic",
"ControlLoop": {
"Proportional": 3,
"Integral": 1,
"Differential": 9
"@odata.id": "/redfish/v1/Controls/PumpPID"
}
}
And we'll need to discuss that property name - because I would normally say that the units (Percent) need to be in the name, but since we already have PumpSpeedPercent naming this control as PumpSpeedControlPercent may be unnecessary? Maybe just SpeedControlPercent as we're in the Pump resource. (and I remember now that we named it PumpSpeedPercent because SpeedPercent didn't feel like enough context)
Jeff
|
|
|
|
Post by jautor on Mar 21, 2024 4:16:15 GMT
Are you looking for the "alert" that the Emergency Shut Off has been used/triggered, or are you looking for the mechanism to initiate an emergency shut off?
For the "alert", you can use a combination of Status/Health to show a "Critical" Health of the resource, and placing a message in Status/Conditions to explain what has triggered that case. We have not defined a standard message for "Emergency Shut Down" - but that clearly is something that could be used across the industry, so we'd certainly take a look at any suggestion there to add to a Message Registry (probably belongs in both the Power and Environmental message registries).
If you want to actually initiate an emergency shut down, I'd probably suggest that it would be best implemented as an Action, with the results shown in the Status/Conditions. So to understand this correctly, an action can do a multi-step process following a POST command? i.e the Action "EmergencyStop" could be posted to the Pump resource, which will set PumpSpeedPercent to 0 and give a Condition that states the pump had an emergency stop. Yes, and that is a perfect example. We use "Actions" to allow for operations that don't nicely into the RESTful semantics, or when it just gets too cumbersome to implement or use. So yes, an Action defined for "EmergencyStop" could allow the service to do both of those things - set pump speed to zero, and place a message in Status/Conditions for "Pump Emergency Stop Initiated." (and change the Status/Health and Status/State as well). The difference there being that a PATCH to just set PumpSpeedPercent to 0 wouldn't cause any of those other responses. Yes, I just didn't include that in the example - you'd absolutely have the ability to place the DataSourceUri property within that object to point to the Control resource (it's not an @odata.id object, but still provides the URI) Jeff |
|
