FRU And FRU Properties In Redfish

puranik
Minnow

Posts: 8

FRU And FRU Properties In Redfish May 21, 2020 14:24:45 GMT

Quote

Post by puranik on May 21, 2020 14:24:45 GMT

Hi,

On IBM systems running OpenBMC, we have requirements to model the following Field Replaceable Units (FRUs) in Redfish (for inventory display and management purposes).

Voltage Regulator Modules (VRMs) - These are regulators for Processors/DIMMs and are plug-able and serviceable FRUs.
Trusted Platform Module (TPM) - These are FRUs used by the system firmware for secure boot and other security purposes.
Battery FRU - These are plug-able battery FRUs that act as a backup to the system's Real Time Clock (RTC) chip.
Operator Panels - These FRUs are panels (display + buttons) that can be used to physically control the Server operation.
Disk Backplanes - These are FRUs that are used to attach internal storage such as NVMe and Disks.

For each of these FRUs, we require the following properties:

IndicatorLED - Each of the above FRUs have an associated LED that is used to indicate Fault and identify the FRU's location.
A Location Code - Think of this as a string that uniquely identifies the part on the system. This can be used to physically locate the part when servicing the system, for example. More information on location codes can be found here: www.ibm.com/support/knowledgecenter/POWER8/p8ecs/p8ecs_locations.htm#locations__locationoverview
A FRU Part Number - This is slightly different than a "Part Number" (which I see is already defined in Redfish). A FRU part number can be considered a slightly higher level to a part number. A FRU part number is what is used when a part needs to be replaced in the field.
A Custom Card Identification Number (CCIN) - This at IBM is a four character string that is even higher level than the part number and is used to track parts by their function.

The questions we have for this forum are:

What is the best way to represent a "FRU" in Redfish. I see that there are schemas dedicated to Manager (BMC), Power Supplies, Fans etc .. but I don't see anything that can fit in the above FRU types (or any generic FRU, for that matter)
Does the property ServiceLabel property in redfish.dmtf.org/schemas/v1/Resource.v1_9_1.json#/definitions/PartLocation map to our use case of the Location Code?
Does the SparePartNumber property in redfish.dmtf.org/schemas/v1/Assembly.v1_2_3.json map to a FRU Part Number?
Does the Model property in redfish.dmtf.org/schemas/v1/Assembly.v1_2_3.json map to a CCIN?

Feedback here is appreciated!
Thanks,
Santosh

jautor
Administrator

Posts: 519

FRU And FRU Properties In Redfish May 25, 2020 19:06:20 GMT puranik likes this

Quote

Post by jautor on May 25, 2020 19:06:20 GMT

Hi Santosh,

The Assembly schema is the way to represent an "FRU" in Redfish where there's not a more specific schema definition. The purpose was to avoid creating additional resources for components in a system that had little or no data of interest to an end user beyond the identification information needed for service. So "small" items like VRMs, battery modules, passive backplanes, etc. can be modeled as one or more items in an Assembly instance under the Chassis resource.

We defined a number of common "FRU" definitions in Assembly for "SparePartNumber", "EngineeringChangeLevel", "Vendor", and others so that information could be conveyed to end users in an interoperable fashion. How those properties map to each vendor's internal terminology is hopefully something that companies specify for their own consistency. There is an "Oem" section available if it makes sense to add OEM-specific properties like "CCIN".

The Assembly resource was intended to be read-only, so IndicatorLED isn't defined there. The Status of each Assembly item is available to indicate fault conditions. But the ability to light a location LED is not currently defined.

Jeff

puranik
Minnow

Posts: 8

FRU And FRU Properties In Redfish May 29, 2020 4:17:17 GMT

Quote

Post by puranik on May 29, 2020 4:17:17 GMT

Thanks for your response, Jeff! Some more questions:

May 25, 2020 19:06:20 GMT jautor said:

Hi Santosh,

The Assembly schema is the way to represent an "FRU" in Redfish where there's not a more specific schema definition. The purpose was to avoid creating additional resources for components in a system that had little or no data of interest to an end user beyond the identification information needed for service. So "small" items like VRMs, battery modules, passive backplanes, etc. can be modeled as one or more items in an Assembly instance under the Chassis resource.

That makes sense to me. So FRUs that are contained within a Chassis could be modeled as "Assemblies" within that chassis.

May 25, 2020 19:06:20 GMT jautor said:

We defined a number of common "FRU" definitions in Assembly for "SparePartNumber", "EngineeringChangeLevel", "Vendor", and others so that information could be conveyed to end users in an interoperable fashion. How those properties map to each vendor's internal terminology is hopefully something that companies specify for their own consistency. There is an "Oem" section available if it makes sense to add OEM-specific properties like "CCIN".

Thanks, so if I read that right, the interpretation of some of these properties within the AssemblyData are left up to implementation?
The AssemblyData does contain most of the data we are interested in representing (from my original post). However, do you think it makes sense to add a Location property
under the AssemblyData object to map to a "FRU location" that can be used to service the FRU?

May 25, 2020 19:06:20 GMT jautor said:

The Assembly resource was intended to be read-only, so IndicatorLED isn't defined there. The Status of each Assembly item is available to indicate fault conditions. But the ability to light a location LED is not currently defined.

Jeff

Is this something that can be added to the AssemblyData too?

jautor Administrator Posts: 519	FRU And FRU Properties In Redfish May 29, 2020 14:41:52 GMT puranik likes this Quote Select Post Deselect Post Link to Post Back to Top Post by jautor on May 29, 2020 14:41:52 GMT Yes, we discussed these in the group this week and agreed that both "Location" and support for a location LED should be added. Jeff

Post by puranik on May 21, 2020 14:24:45 GMT

Post by jautor on May 25, 2020 19:06:20 GMT

Post by puranik on May 29, 2020 4:17:17 GMT

Post by jautor on May 29, 2020 14:41:52 GMT