DMTF Tutorial > CIM > CIM Schema > Common Models > Devices Model

CIM Schema - Devices Model

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).