The Common Diagnostics Model, or CDM, is a diagnostics standard developed and maintained by the Distributed Management Task Force

Distributed Management Task Force

Distributed Management Task Force is an industry organization that develops, maintains and promotes standards for systems management in enterprise IT environments. These standards allow for building systems management infrastructure components in a platform-independent and technology-neutral way...

 (DMTF). CDM models the entire flow of diagnosis from test discovery, configuration and execution to progress updates and execution controls to finally viewing and managing the test results. It is based on the Common Information Model

Common Information Model (computing)

The Common Information Model is an open standard that defines how managed elements in an IT environment are represented as a common set of objects and relationships between them...

(CIM) and the Web-Based Enterprise Management standards defined by the DMTF.


CDM establishes an industry standard diagnostics interface enabling the seamless integration of diagnostic services into system management frameworks and is both platform and OS independent.

History of CDM

Efficiently maintaining computing solutions from the datacenter to the desktop is a vital concern for end-users, OEMs, ISVs, and integrators alike. Today, the maintenance of hardware in system solutions requires the use of an endless array of uncoordinated diagnostic tools and applications which decreases agility, increases time-to-repair, and management overhead. Even a single computer has sub-systems that are supplied by an array of vendors each having disparate diagnostic technology. Ultimately, this inefficiency deters IT consumers from aggressively expanding computing resources to meet demand and decreases business efficiency. Indeed, a central value proposition for modern autonomic computing systems are their ability to automatically detect failing hardware components and adaptively redirect applications to stable resources be it servers, networking components, or storage. Today, computing systems deliver little towards this vision principally due to the incompatible management APIs that traverse multi-vendor diagnostic programs today. This vision is further deterred due to the lack required functionality and security in interfaces to diagnostic routines.

In September 2006 the DMTF launched the Common Diagnostic Model (CDM) Health Management Initiative to, for the first time, unify the computer industry on a single interoperable, secure, and functionally rich interface to diagnostics programs on multi-vendor computer systems. CDM is based on the Common Information Model (CIM) and Web Based Enterprise Management (WBEM) standards as pioneered by the Distributed Management Task Force (DMTF). The CDM Health Management Initiative brings together the vast resources of the DMTF including: Education, Development Tools, Interoperability, Technical Work Groups, and Marketing, to fundamentally improve the efficiency of the computer industry in delivering more advanced software solutions as well as to directly decrease the cost of datacenter management. Via CDM technology, hardware suppliers will no longer need to develop unique diagnostic solutions for their various customers, IHVs will trim diagnostic development investment, Independent Software Vendors will benefit by having a single vehicle to deliver adaptive software systems, and Original Equipment Manufacturers will benefit by having an improved level of support from their vendors.

CDM Forum

The CDM Forum is the center of the CDM Health Initiative and functions similar to a DMTF Working Group or a DMTF Committee. The CDM Forum has additional responsibilities that go beyond a Working Group. The fiscal responsibilities of the CDM forum allow it to achieve results above and beyond that of a Working Group. The CDM Forum is responsible for securing the financial resources necessary to ensure that the broader industry ultimately achieves the architectural vision of the technology. While self governed, the CDM Forum assures adherence to all DMTF bylaws, policies and procedures by reporting through the DTMF Interoperability Committee. This hierarchy allows visibility of the CDM Forum’s activities all the way to the DMTF Board of Directors, while not burdening the Interoperability Committee with the day-to-day workload of governing the CDM Forum’s activities

The CDM Forum will drive the industry wide adoption of CDM by providing the ability for the industry to develop conforming health management solutions based on CDM. More advanced and interoperable diagnostic solutions will have a mutually beneficial affect for all companies that participate in the CDM Forum. The key elements that will make this goal possible are: Compliance testing tools; Use cases and profiles; as well as a certification program.

Basic Concepts and Terminology

The term diagnostics has been used to describe a variety of problem-determination and prevention tools, including exercisers, excitation/response tests, information gatherers, configuration tools, and predictive failure techniques. The focus of the CDM is the enabling infrastructure that describes diagnostic applications and the capabilities of these applications.

The CDM extends the CIM schema to cover the management of diagnostics, including diagnostic tests, executives, monitoring agents, and analysis tools. The objective of diagnostic integration into CIM is to provide a framework in which industry-standard building blocks that contribute to the ability to diagnose and predict the system's health can seamlessly integrate into enterprise management applications and policies.

The diagnostic model also leverages other areas of the CIM model to provide extended diagnostic capabilities rather than introducing diagnostic-centric mechanisms. Examples are the jobs model for monitoring, the log model for capturing information, and effective use of the logical and physical models.

Diagnostic Service

Diagnostic services share the semantics of the CIM model regardless of whether the service launches tests, starts a monitoring agent, or enables instrumentation. They share the same mechanisms for publishing, method execution, parameter passing, message logging, and reporting Field Replaceable Unit (FRU) information.

These services are more than just test applications. Diagnostics create controlled stimuli and monitor, gather, record, and analyze information about detected faults, state, status, performance, and configuration. Because of its diverse uses, diagnostics is best modeled as a service that launches or enables the components necessary to implement the diagnostic actions requested by the client.

Managed Elements

Diagnostics are applied to managed elements. Applied means that a test checks a managed element, a diagnostic daemon monitors a managed element, diagnostic instrumentation is built into the managed element, and so on. One of the goals of CIMbased diagnostics is the packaging of diagnostics with the vendors deliverable or FRU. Thus diagnostics are often applied at the FRU level of granularity.

Diagnostic Control

CDM clients may need to control and monitor the status and progress of the diagnostics elements that the service provider launches to implement a service request. Clients achieve this control and monitoring capability in a generic manner by using the CIM job and process model. The elements launched by the diagnostic service can be collectively controlled and monitored through an instance of ConcreteJob that is returned by the diagnostics start method in the diagnostic service.

Diagnostic Logging and Reporting

The ultimate goal of running a diagnostic service is to collect information about the health of a managed element. Clients specify how this information needs to be recorded in order to be useful in the problem-determination process. Logged information may be analyzed by a client dynamically for fault containment and system-recovery purposes, but in many situations the information is gathered for post-mortem analysis in message logs for use by field service technicians or quality assurance personnel. Examples of relevant information include:

• Fault Analysis: Diagnostic error codes, error frequency, warnings, test time, resource allocation, and percent completion may all be relevant when analyzing failures.
• Tracking FRU Health: Diagnostics can query the system to acquire FRU information relevant to diagnostics, such as health history, replacement information, and fault signatures.
• Reproducing Failures: Diagnostics can query the system to get configuration and state information from the managed elements to which they are applied, from those elements that are impacted by the diagnostic, and from elements that impact the diagnostic itself.

Diagnostic Test

A CDM client uses the properties included in the DiagnosticTest class to determine the general effects associated with running the test. For example, if a test is going to destroy data or monopolize a resource, the client needs to be aware of this and inform the user or make adjustments to the environment. The methods defined for the test class are included to start the test, stop it prior to normal completion, and clear any stored results that are no longer needed.

A primary function of this class is to publish information about the device(s) that it services and the effects that running the service has on the rest of the system. The diagnostic service publishes the following information:

• Name and description of the diagnostic service instance
• Characteristics unique to the diagnostic service type
• Diagnostic capabilities implemented by the diagnostic service
• Default settings that the diagnostic service applies
• Effects on other managed element

Diagnostic Setting

DiagnosticSetting is derived from CIM_Setting and is used to contain the default and run-specific settings for a given test. Diagnostic service providers publish default settings in an instance of this class (associated to the service by an instance of DefaultSetting), and CDM clients create a new instance and populate it with these defaults with, possibly, user modifications. This new setting object is then passed as an input parameter to RunTest.

Diagnostic Capabilities

DiagnosticSetting object are "qualified" by corresponding properties in DiagnosticServiceCapabilities. If the capabilities do not include support for a particular setting, the client must maintain the default for that setting.

Diagnostic Jobs

ConcreteJob : Job, introduced in CIM 2.7, provides the properties and methods needed for controlling a diagnostic component (for example, test application) that was launched by the diagnostic service. It also includes most of the monitoring properties relevant to diagnostics, such as percent complete, error code, and job status. CDM's use of the ConcreteJob class produces implementations that separate the service monitoring and control functions from the results logging and service publication classes.

The ConcreteJob class represents the currently executing service. It is associated with the DiagnosticService that created it through the OwningJobElement association. ConcreteJob contains the following functionality: April 6, 2005 26 CIM Diagnostics Model White Paper Version 1.0

• The job state can be queried.
• Jobs can be suspended and resumed by invoking the RequestStateChange method of the ConcreteJob class (added in CIM 2.8).
• Jobs can be associated with specific MEs using the AffectedJobElement association. Within this association is the ElementEffects property. A diagnostic service, when represented by a job, can indicate it is affecting multiple MEs, and indicate the nature of that effect.

Diagnostic Results

CIM_MessageLog (now a child of CIM_Log) was designed to act both as a container for freeform records with methods for managing them and as an aggregation point for LogRecord objects. Having separate classes for these two log mechanisms was more object-oriented, so RecordLog was introduced as a peer of MessageLog. RecordLog is strictly an aggregation point, having no extrinsic methods. This class fits the diagnostic model in a more efficient manner, as will be shown. An empty subclass of RecordLog, DiagnosticsLog, was added to allow the development of a consolidated record management methodology for diagnostics. A common set of providers for this log and its associated records should be used to control functions such as record persistence, query support, and overall data integrity in a consistent manner.

CIM_RecordForLog : CIM_ManagedElement is an abstract parent of LogRecord and DiagnosticRecord, introduced in CIM 2.9 to allow these record classes to have a different key structures. LogRecord remains Weak to MessageLog (via the RecordInLog aggregation) and has the propagated keys from MessageLog. DiagnosticRecord has the simpler, preferred, InstanceID key and uses the (non-Weak) LogManagesRecord aggregation, defined at the CIM_Log level.

Use Cases

This section describes some of the common use cases for CDM tests (subtests) and packages (groups of subtests).

The CDM Environment provides the following abilities:

• CDM Test discovery and hardware association to specific components in a system
• Test behavior customization and runtime execution control
• Test log gathering and test pass/fail results

A CDM compliant Client would be needed at the top level to manage the CDM Environment. This could be a local client that resides on the Unit Under Test (UUT) or a Remote Client that can connect to the CDM supported CIMOM (CIM Object Manager).

On the CDM diagnostics side, implementation use cases can include the following:

Manufacturing

• Different types of manufacturing:
  • Vendors can use CDM to validate their components prior to shipment
  • OEMs can use CDM to validate system assembly components
• Can be used to validate system components (e.g., HDD, ODD, CPU, etc.) prior to shipment
• Can be used to stress test component(s) in a system
• Can utilize looping of tests to conduct a burn-in type test (similar to stress test)
• Can be used during a debug phase, for instance if a system failed an initial test sequence a technician could use CDM to test a specific component for a more thorough diagnosis

IT Infrastructure

• Two types of CDM tests can be developed
  • Off-line: diagnostics that require a bootable environment to run isolated
  • On-line: diagnostics that are non-evasive and non-desctuctive that can be run while a customer system is up and running
• Can be used to by call centers to validate system components (e.g., HDD, ODD, CPU, etc.) in the field
• Can be used to troubleshoot (drill down) an issue on a specific component on the Field
• Can be used to stress test component(s) in a field system (off-line)

Data Center

• Very similar to IT Infrastructure, providing the next troubleshooting level down to diagnostics within manageability
• Provide a conduit for manageability to run subcomponent diagnostics to troubleshoot managed components and subcomponents
• Two types of CDM tests can be developed
  • Off-line: diagnostics that require a bootable environment to run isolated
  • On-line: diagnostics that are non-evasive and non-desctuctive that can be run while a customer system is up and running
• Can be used to by call centers to validate system components (e.g., HDD, ODD, CPU, etc.) in the field
• Can be used to troubleshoot (drill down) an issue on a specific component on the Field
• Can be used to stress test component(s) in a field system (off-line)

Field Support

• Can be used by a Field Engineer on an initial install to validate a system's functionality before bringing it online
• Can be used by a Field Engineer to determine health status of suspect components

Repair Depot

• Can be used by a Repair Technician to validate components in a returned system and isolate failures
• Can be used by a Repair Technician to determine if the repair process was successful

CDM Conformance Program

The CDM Conformance Program (CDM CP) is designed to validate CDM implementations to a particular version of the CDM Implementation Requirements Specification and is managed and sponsored by the CDM Forum. CDM is used to evaluate the health of computer system components in multivendor environments. It specifies diagnostics instrumentation that can be utilized by vendors (OEMs and system builders) and platform management applicants to determine the health of a computer system components.


Companies interested in participating in the CDM CP self-test their implementation using the applicable CDM Conformance Test Suite and submit their digitally signed results to the CDM Conformance Program Administrator (an independent third party) for validation. The results will be validated by the Conformance Program Administrator. Certified results may be submitted for inclusion in the DMTF Certification Registry.


Click here to review the latest DMTF CDM Certified products.

External links

• www.dmtf.org - Official DMTF website