Subclasses of CIM_PhysicalElement define any component of a system that has a distinct physical identity. Instances of this class can be defined in terms of labels that can be physically attached to the object. All processes, files, and logical devices are considered not to be physical elements. For example, it is not possible to attach a label to a modem. It is only possible to attach a label to the card that implements the modem. The same card could also implement a LAN adapter. These are tangible managed system elements (usually actual hardware items) that have a physical manifestation of some sort. A managed system element is not necessarily a discrete component. For example, it is possible for a single card (which is a type of physical element) to host more than one logical device. The card would be represented by a single physical element associated with multiple logical devices.
CIM_PhysicalElement - child subclasses in ROOT\cimv2
'CreationClassName indicates the name of the class or the subclass used in the creation of an instance. When used with the other key properties of this class, this property allows all instances of this class and its subclasses to be uniquely identified.'
'The name of the organization responsible for producing the physical element. This may be the entity from whom the element is purchased, but this is not necessarily true. The latter information is contained in the Vendor property of CIM_Product.'
'OtherIdentifyingInfo captures additional data, beyond asset tag information, that could be used to identify a physical element. One example is bar code data associated with an element that also has an asset tag. Note that if only bar code data is available and is unique/able to be used as an element key, this property would be NULL and the bar code data used as the class key, in the tag property.'
'An arbitrary string that uniquely identifies the physicalelement and serves as the element's key. The Tag property can contain information such as asset tag or serial number data. The key for CIM_PhysicalElement is placed very high in the object hierarchy in order to independently identify the hardware/entity, regardless of physical placement in or on cabinets, adapters, etc. For example, a removable component that can be hot swapped, may be taken from its containing (scoping) package and be temporarily unused. The object still continues to exist - and may even be inserted into a different scoping container. Therefore, the key for physicalelement is an arbitrary string and is defined independently of any placement or location-oriented hierarchy.'
'The InstallDate property is datetime value indicating when the object was installed. A lack of a value does not indicate that the object is not installed.'
'The Status property is a string indicating the current status of the object. Various operational and non-operational statuses can be defined. Operational statuses are "OK", "Degraded" and "Pred Fail". "Pred Fail" indicates that an element may be functioning properly but predicting a failure in the near future. An example is a SMART-enabled hard drive. Non-operational statuses can also be specified. These are "Error", "Starting", "Stopping" and "Service". The latter, "Service", could apply during mirror-resilvering of a disk, reload of a user permissions list, or other administrative work. Not all such work is on-line, yet the managed element is neither "OK" nor in one of the other states.'
'Subclasses of CIM_PhysicalElement define any component of a system that has a distinct physical identity. Instances of this class can be defined in terms of labels that can be physically attached to the object. All processes, files, and logical devices are considered not to be physical elements. For example, it is not possible to attach a label to a modem. It is only possible to attach a label to the card that implements the modem. The same card could also implement a LAN adapter. These are tangible managed system elements (usually actual hardware items) that have a physical manifestation of some sort. A managed system element is not necessarily a discrete component. For example, it is possible for a single card (which is a type of physical element) to host more than one logical device. The card would be represented by a single physical element associated with multiple logical devices.'