Best way to implement accessory sensors/actors of a PDU

Well, that's a great start!



Yes, we've had discussions about these types of accessory devices, and how they should be supported in the model.

The basic design tenet conclusion I came to is that regardless of how a particular device/sensor gets deployed (as an accessory or as an in-built part of a piece of equipment), it should be treated the same in the data model. Meaning, if I have a temperature sensor accessory that I placed at the top of a rack, and another rack has one built in, those should both show up in the same place in the model, as any client attempting to read the rack temperature doesn't care how it got there.



Sticking for the moment with "environmental sensors", we've consolidated the places within the data model where the SensorCollection should land. With the just-release 2022.3 schema, the collections under PowerDistribution have been deprecated, in favor of a more consistent model where the Sensors are always shown under a Chassis instance.

The intent here is to prevent a scattering of Sensors - but also understanding that clients will learn the context for a particular sensor by its use in a "functional-model" resource as an Excerpt. For example, a Circuit (functional model) resource has a bunch of sensor excerpts for voltage, current, power, frequency, etc. And that's the primary path users would start from - and follow the `DataSourceUri` links to the Sensor resource. And that SensorCollection will reside under a Chassis (the physical model) that likely consolidates a bunch of sensors. In this way, the context for that "use" of that sensor is already known, because the excerpt is shown in that (functional model) resource.

Now, when there are sensors just placed "somewhere in the room", our current answer is that there still needs to be some Chassis (probably the device that holds the connectors those accessories attach to) to hold those in a SensorCollection. But for the functional "view", we have the Facility resource that contains an EnvironmentMetrics, where those types of sensors are shown in excerpts. (and FYI, we also have AmbientMetrics, to show sensor data for outdoor conditions).

So that suggests that when the user configures an accessory sensor, the software would render a Facility resource to hold those "room conditions", or allow them to either choose a managed Chassis resource, or create a new one (hopefully matching names and using links to show the containment hierarchy). The `Location` property has lots of potential to give some structure to the user-supplied text strings.



Your diagram is along the same line of thinking I have - that you'll need something like your "Accessory" collection that shows the "unconfigured" capabilities of each possible accessory - whether that is a generic "plug" or a dedicated sensor type, those things will still need to be configured for their placement, etc. My thought is that once an accessory is configured, it would populate a Sensor resource in the Chassis used for your product (and we'd really like all physical products to have a Chassis resource), and in addition, that Sensor could populate an excerpt in whatever context the user configured (likely an EnvironmentMetrics instance under another Chassis or Facility).

That allows a consistent view of the end results - some number of sensors in their context, regardless of how they "got there".



Yes, we have avoided non-numeric readings for a "Sensor". There's a lot of detail as to why, but the short answer is that whenever we've drilled into why someone needed that capability, it was typically someone taking a shortcut in the model at the expense of usability and interoperability... Those true/false sensors represent two states of some device - and in the cases we've been presented, those have all been better handled by defining actual properties that represent those two states. Or better still, the combination of three or more states. For example (and this is not in the Redfish model today), one switch can show a door open/closed and another locked/unlocked. We'd want to represent that with a `DoorState` property with possible values of "Open | Closed | Locked".

Now, there will likely be cases where the user has some wild use that will never match a pre-defined standard use case. And at least for now, we've left that to OEM extensions.



We do have cases where a single sensor provides more than one value at the same time, and those values must be shown together to be valid and time-coherent. For those cases, we add properties to the Sensor resource for those specific cases. For example, the `Power` sensor can show `ApparentVA` and `ReactiveVAR` in addition to the real power shown as the `Reading`. In those cases, there's a consistent primary value that can be reported as the Reading for consistency, with the additoinal properties available as options.

For an acceleration sensor, I would assume we could pick one direction (X?) as the Reading, and add two properties for `Y` and `Z` that would be reported together. I'm assuming that would allow us to model both a linear acceleration and full 3D motion. That's exactly the type of feedback we can easily incorporate if that fits your use case.



The OData specification (where the $metadata definitions come from) requires that all schemas represented need to be referenced in the $metadata file. Now, that said, we know there will be cases where the product providing the Redfish service will not be able to know all of those references (any aggregator will run into that issue), and there are very few (if any) generic OData clients in the wild that could make use of that information anyway.

Also, there is no requirement that these schemas be stored "on chip" (i.e. in the /Schemas URI tree) - although it's recommended to ensure schema-aware clients can obtain them without Internet access.

DMTF members can request to "re-publish" their OEM schemas on the DMTF website, so they can be accessed just like the standard schemas.

Whew! That's a lot in one reply... But hope that at least starts to answer some of your questions.

Jeff

Good, that's a fairly simple solution.



Oh, I like that much better. We want each Sensor to always return a `Reading` - and your suggestion provides a useful value while allowing the 3 axis-specific values as three easy-to-understand additional properties/values. My thought was that the `Reading` being the x-axis value could be useful for a linear accelerator/position - but that still works, and the property names are much more descriptive and clear...

Jeff

Take a look at Controls for those outputs.

But our thinking on configurable inputs/outputs that they show up in the standard Redfish model once they have been configured to be "something" that is available in the standard resource definitions. So an input configured (with proper hardware) to be a temperature sensor for a rack would show up as such - and be reported in the EnvironmentMetrics for the Chassis that represents the rack. Until that configuration has been performed, we don't have a standard model to show that "unconfigured input/output" - and it's not clear if there's a benefit for attempting to standardize that. I think there are so many options and possibilities that there would be no interoperable overlap among vendors/implementations, so just do an OEM definition that meets your needs, and ensure those devices show up in the standard locations and models once they have been configured...

And if there's more Control or Sensor types to add to the standard, of course, let us know!



No, a Chassis instance could just be a physical container, likely with some product identification (make/model/serial number) and with perhaps some environment sensors. We envisioned a Rack to be just that - a way to show the physical location of a bunch of gear that share a common piece of infrastructure, with their position in the rack and external sensors that provide "rack level" temperature, power consumption, etc. reported in one place that can be associated with all the individual pieces enclosed.


Jeff