|
DMTF Tutorial
> CIM > CIM
Schema > Common Models > Devices Model
 |
CIM Schema - Devices Model
|
 |
Overview | CIM Specification | CIM Schema | Extension Schema
Core Model
| Common Models
The CIM Device Common Models describes the functionality provided
by hardware, as well as providing configuration and state data.
The model covers a wide breadth of hardware. It addresses low-level
concepts such as sensors, batteries and fans, and high-level abstractions
such as Storage Volumes.
There are several important concepts related to a CIM_LogicalDevice:
- Devices represent the abstract concepts of the functionality,
configuration and state of hardware. They have a "Realized" relationship
referencing the hardware that they describe.
- Typically a single hardware component provides multiple functionalities
that are realized as multiple different LogicalDevices.
- The configuration of the underlying hardware and software is
critical to managing the device.
- The interaction between the various devices (i.e. their interconnections)
can play a crucial role in managing the device itself.
- Devices are described as components of a CIM_System that contain
them. This relationship is described by the mandatory SystemDevice
relationship. It has been identified that this single level of
containment makes it difficult to describe a device that is contained
by another element, other than a system.
Disk Drive Example:
The Device Model will not be reviewed in its entirety – because
its scope is too large, addressing all the various aspects of hardware
functionality, configuration and state. In fact, the Device Model
can be broken down to individual components (cooling and power,
processors, storage, etc.) that are managed individually. So, to
understand the model, a specific, rather common example is chosen
– that of a disk drive.
The functionality that we typically associate with a disk drive
includes the:
- PhysicalPackage, which represents the drive mechanism that you
can see and touch – containing storage, the read/write hardware,
on-board flash or EPROMs, etc.
- DiskDrive, which represents the functionality to read/write
data from the medium – realized as a type of MediaAccessDevice.
- StorageExtent, which represents the functionality of the medium
used to storage the data – may or may not be removable.
- Memory, which represents the internal cache buffers.
- SoftwareIdentity, which represents the firmware and device driver
code that is available for the drive.
Then, there are various associations that tie these classes and
concepts together:
- The MediaPresent association is used to tie the StorageExtent
to its DiskDrive.
- The AssociatedMemory association is used to tie the Memory to
its DiskDrive.
- The DeviceSoftwareIdentity association (defined in CIM V2.8)
is used to tie the SoftwareIdentity to its DiskDrive
- The Realizes association is used to tie DiskDrive, StorageExtent,
and Memory to the PhysicalPackage.
It is practical to manage a LogicalDevice in the context of the
System in which it is functioning. Therefore, the next step in the
example is to place the disk drive in the context of a ComputerSystem.
In this example:
The ComputerSystem has a SystemDevice relationship to:
- PowerSupply
- Memory (for the computer system)
- DiskDrive
- StorageExtent
- Memory (for the disk drive)
As noted above, it is cumbersome that the Memory for the
disk drive is a component of the ComputerSystem versus a
component of the disk drive. However, the Memory is associated
to the DiskDrive using the AssociatedMemory relationship.
This indicates that the Memory is indeed "dedicated" to
the drive.
The DiskDrive has the following associations:
- SystemDevice to describe its component relationship to the ComputerSystem
- MediaPresent to describe the dependent relationship with StorageExtent
(its medium).
- AssociatedMemory to describe its usage of Memory.
- Realizes to tie to the PhysicalPackage (hardware).
|
