Document Number: DSP1080

Date: 2014-01-14

Version: 2.0.0a




Enabled Logical Element Profile




IMPORTANT: This specification is not a standard. It does not necessarily reflect the views of the DMTF or all of its members. Because this document is a Work in Progress, this specification may still change, perhaps profoundly. This document is available for public review and comment until the stated expiration date.

This document expires on: 2014-06-30.

Target version for DMTF Standard: 2.0.0.

Provide any comments through the DMTF Feedback Portal: http://www.dmtf.org/standards/feedback



Document Type: Specification

Document Status: Work in Progress

Document Language: en-US




Copyright © 2007-2014 Distributed Management Task Force, Inc. (DMTF). All rights reserved.

DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. Members and non-members may reproduce DMTF specifications and documents, provided that correct attribution is given. As DMTF specifications may be revised from time to time, the particular version and release date should always be noted.

Implementation of certain elements of this standard or proposed standard may be subject to third party patent rights, including provisional patent rights (herein "patent rights"). DMTF makes no representations to users of the standard as to the existence of such rights, and is not responsible to recognize, disclose, or identify any or all such third party patent right, owners or claimants, nor for any incomplete or inaccurate identification or disclosure of such rights, owners or claimants. DMTF shall have no liability to any party, in any manner or circumstance, under any legal theory whatsoever, for failure to recognize, disclose, or identify any such third party patent rights, or for such party’s reliance on the standard or incorporation thereof in its product, protocols or testing procedures. DMTF shall have no liability to any party implementing such standard, whether such implementation is foreseeable or not, nor to any patent owner or claimant, and shall have no liability or responsibility for costs or losses incurred if a standard is withdrawn or modified after publication, and shall be indemnified and held harmless by any party implementing the standard from any and all claims of infringement by a patent owner for such implementations.

For information about patents held by third-parties which have notified the DMTF that, in their opinion, such patent may relate to or impact implementations of DMTF standards, visit http://www.dmtf.org/about/policies/disclosures.php.

CONTENTS

[Insert table of contents here ...]

Figures

[Insert table of figures here ...]

Tables

[Insert table of tables here ...]

Foreword

This document was prepared by the DMTF Architecture Working Group

DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems management and interoperability. For information about the DMTF, see http://www.dmtf.org.

Acknowledgements

DMTF acknowledges the following individuals for their contributions to this document:

Introduction

The information in this specification and referenced specifications should be sufficient for a provider or consumer of this data to identify unambiguously the classes, properties, methods, and values that shall be instantiated and manipulated to represent and manage the common aspects of enabled logical elements that are modeled using the DMTF CIM core and extended model definitions.

The target audience for this specification is implementers who are writing CIM-based providers or consumers of management interfaces that represent the components described in this document.

Document conventions

Typographical conventions

The following typographical conventions are used in this document:

  • Document titles are marked in italics.
  • Important terms that are used for the first time are marked in italics.
  • Terms include a link to the term definition in the "Terms and definitions" clause, enabling easy navigation to the term definition.

OCL usage conventions

Constraints in this document are specified using OCL (see OCL 2.0).

OCL statements are in monospaced font.

Enabled Logical Element Profile

Scope

The Enabled Logical Element Profile is a pattern profile that extends the management capabilities of referencing profiles by adding the capability to represent any enabled logical element. This profile describes common requirements for modeling the variety of enabled logical elements within managed systems including enabled state management, health state, and operational status.

Normative references

The following referenced documents are indispensable for the application of this document. For dated or versioned references, only the edition cited (including any corrigenda or DMTF update versions) applies. For references without a date or version, the latest published edition of the referenced document (including any corrigenda or DMTF update versions) applies.

DMTF DSP0004, CIM Infrastructure Specification 2.7,
http://www.dmtf.org/standards/published_documents/DSP0004_2.7.pdf

DMTF DSP0223, Generic Operations 1.1,
http://www.dmtf.org/standards/published_documents/DSP0223_1.1.pdf

DMTF DSP1001, Management Profile Specification Usage Guide 1.2,
http://www.dmtf.org/standards/published_documents/DSP1001_1.2.pdf

DMTF DSP1103, Job Control Profile 1.0,
http://www.dmtf.org/standards/published_documents/DSP1103_1.0.pdf

OMG formal/06-05-01, Object Constraint Language 2.0,
http://www.omg.org/spec/OCL/2.0/

ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards,
http://isotc.iso.org/livelink/livelink?func=ll&objId=4230456&objAction=browse&sort=subtype

Terms and definitions

In this document, some terms have a specific meaning beyond the normal English meaning. Those terms are defined in this clause.

General

The terms "shall" ("required"), "shall not", "should" ("recommended"), "should not" ("not recommended"), "may", "need not" ("not required"), "can" and "cannot" in this document are to be interpreted as described in ISO/IEC Directives, Part2, Annex H. The terms in parenthesis are alternatives for the preceding term, for use in exceptional cases when the preceding term cannot be used for linguistic reasons. Note that ISO/IEC Directives, Part2, Annex H specifies additional alternatives. Occurrences of such additional alternatives shall be interpreted in their normal English meaning in this document.

The terms "clause", "subclause", "paragraph", "annex" in this document are to be interpreted as described in ISO/IEC Directives, Part2, Clause 5.

The terms "normative" and "informative" in this document are to be interpreted as described in ISO/IEC Directives, Part2, Clause 3. In this document, clauses, subclauses or annexes indicated with "(informative)" as well as notes and examples do not contain normative content.

The terms defined in DSP0004, DSP0223, and DSP1001 apply to this document.

The following additional terms are defined in this document.

enabled logical element

a logical element that has a concept of enabled state associated with it.

Symbols and abbreviated terms

The abbreviations defined in DSP0004, DSP0223, and DSP1001 apply to this document.

This document does not define any additional abbreviations.

Synopsis

Profile name:  Enabled Logical Element

Version:  2.0.0

Organization:  DMTF

Abstract:  No

Profile type:  Pattern

Schema:  DMTF CIM 2.24

The Enabled Logical Element profile is a pattern profile that extends the management capability of the referencing profiles by adding a common representation of enabled logical elements.

identifies the profile references defined in this profile.

Profile references
Profile reference name Profile name Organi-​zation Version Relation-​ship Description
JobControl Job Control DMTF 1.0 Conditional

Condition:

The AsynchronousRequestStateChange feature is implemented.

identifies the features defined in this profile.

Features
Feature Requirement Description
Capabilities Conditional See subclause "Feature: Capabilities".
EnabledStateRepresentation Conditional See subclause "Feature: EnabledStateRepresentation".
EnabledStateManagement Conditional See subclause "Feature: EnabledStateManagement".
AsynchronousRequestStateChange Optional See subclause "Feature: AsynchronousRequestStateChange".
ElementNameRepresentation Conditional See subclause "Feature: ElementNameRepresentation".
ElementNameModification Optional See subclause "Feature: ElementNameModification".

identifies the class adaptations defined in this profile.

Adaptations
Adaptation Elements Requirement Description
Instantiated, embedded and abstract adaptations
EnabledLogicalElement CIM_EnabledLogicalElement Mandatory See subclause "Adaptation: EnabledLogicalElement".
ElementCapabilities CIM_ElementCapabilities Conditional See subclause "Adaptation: ElementCapabilities".
EnabledLogicalElementCapabilities CIM_EnabledLogicalElementCapabilities Conditional See subclause "Adaptation: EnabledLogicalElementCapabilities".
ConcreteJob CIM_ConcreteJob See embedding elements See subclause "Adaptation: ConcreteJob".
Indications and exceptions
This profile does not define any such adaptations.

identifies the use cases and state descriptions defined in this profile.

Use cases and state descriptions
Name Description
State description: SimpleScenario See subclause "State description: SimpleScenario".
State description: ResetStateTransitions See subclause "State description: ResetStateTransitions".
Use case: DetermineLevelOfStateManagement See subclause "Use case: DetermineLevelOfStateManagement".
Use case: EnableElement See subclause "Use case: EnableElement".
Use case: DisableElement See subclause "Use case: DisableElement".
Use case: ResetElement See subclause "Use case: ResetElement".
Use case: DetermineElementNameModifiable See subclause "Use case: DetermineElementNameModifiable".

Description

The Enabled Logical Element profile is a pattern profile that describes the common set of attributes and behavior for enabled logical elements. The profile also specifies a set of properties representing the enabled state, the requested state and the current operational and health status of managed elements, an optional method for the initiation of enabled state changes, and an optional capability class conveying information about supported requested states and support for client state management and client modification of the ElementName property.

The adaptation diagram in shows all class usages (adaptations) defined in this profile.

Adaptation diagram

The EnabledLogicalElement class adaptation contains properties to represent the enabled state, different aspects of the operational status, and health state. The EnabledLogicalElementCapabilities adaptation associated to the EnabledLogicalElement through ElementCapabilities represents the capabilities of the associated enabled logical element.

State and status properties

The current state and status of an enabled logical element is represented using the following properties on its EnabledLogicalElement instance:

Consistency between PrimaryStatus, HealthState and OperationalStatus

Non-Null values of the properties PrimaryStatus, HealthState, and of the first array entry of OperationalStatus (that is, OperationalStatus[0]) need to be consistent as described in :

Consistency between PrimaryStatus, HealthState and OperationalStatus[0]
PrimaryStatus HealthState OperationalStatus[0]
0 (Unkown) 0 (Unkown) 0 (Unkown)
1 (OK) 5 (OK) 2 (OK)
2 (Degraded) 10 (Degraded/Warning) 3 (Degraded)
2 (Degraded) 15 (Minor Failure) 3 (Degraded)
3 (Error) 20 (Major Failure) 6 (Error)
3 (Error) 25 (Critical Failure) 6 (Error)
3 (Error) 30 (Non-recoverable Error) 6 (Error)

Consistency between CommunicationStatus and OperationalStatus

If the OperationalStatus property is non-Null (that is, implemented) and any of its array entries has one of the values listed in , the CommunicationStatus property if non-Null (that is, implemented) needs to have the corresponding value listed in .

Consistency between CommunicationStatus and OperationalStatus[]
OperationalStatus[] value Required value for CommunicationStatus
12 (No Contact) 4 (No Contact)
13 (Lost Communication) 3 (Lost Communication)

Implementation

Features

Feature: Capabilities

Requirement level:

Conditional

Condition:

At least one of the following is true:

Implementing this feature for an enabled logical element provides support for representing the capabilities of the element.

This feature can be made available to clients at the granularity of EnabledLogicalElement instances.

It can be concluded that the feature is available for a EnabledLogicalElement instance if:

Otherwise, it can be concluded that the feature is not available.

Feature: EnabledStateRepresentation

Requirement level:

Conditional

Condition:

The EnabledStateManagement feature is implemented.

Implementing this feature for an enabled logical element provides support for representation of the enabled state of the element.

If this feature is implemented for an enabled logical element, the following constraints apply:

If this feature is not implemented for an enabled logical element, the following constraints apply:

This feature can be made available to clients at the granularity of EnabledLogicalElement instances.

It can be concluded that the feature is available for a EnabledLogicalElement instance if:

Otherwise, it can be concluded that the feature is not available.

Feature: EnabledStateManagement

Requirement level:

Conditional

Condition:

The AsynchronousRequestStateChange feature is implemented.

Implementing this feature for an enabled logical element provides support for client management of the enabled state of the element.

Implementing this feature for an enabled logical element requires that the EnabledStateRepresentation and Capabilities features are also implemented for that element.

If this feature is implemented for an enabled logical element, the following constraints apply:

If this feature is not implemented for an enabled logical element, the following constraints apply:

This feature can be made available to clients at the granularity of EnabledLogicalElement instances.

It can be concluded that the feature is available for a EnabledLogicalElement instance if:

Otherwise, it can be concluded that the feature is not available.

Feature: AsynchronousRequestStateChange

Requirement level:

Optional

Implementing this feature for an enabled logical element provides support for asynchronous execution of the RequestStateChange( ) method of the EnabledLogicalElement adaptation.

Implementing this feature for an enabled logical element requires that the EnabledStateManagement feature is also implemented for that element.

If this feature is implemented for an enabled logical element, the RequestStateChange( ) method shall support asynchronous execution. Note that the method implementation may decide between synchronous and asynchronous execution on every invocation individually.

If this feature is not implemented for an enabled logical element, the RequestStateChange( ) method shall not support asynchronous execution; any invocations of the method shall be performed synchronously.

This feature can be made available to clients at the granularity of EnabledLogicalElement instances.

Availability of this feature cannot be discovered by clients (other than trying the functionality provided by the feature).

Feature: ElementNameRepresentation

Requirement level:

Conditional

Condition:

The ElementNameModification feature is implemented.

Implementing this feature for an enabled logical element provides support for representing its element name (that is, the ElementName property of the EnabledLogicalElement instance representing the element).

If this feature is implemented for an enabled logical element, the ElementName property shall be non-Null.

If this feature is not implemented for an enabled logical element, the ElementName property shall be Null.

This feature can be made available to clients at the granularity of EnabledLogicalElement instances.

It can be concluded that the feature is available for a EnabledLogicalElement instance if:

Otherwise, it can be concluded that the feature is not available.

Feature: ElementNameModification

Requirement level:

Optional

Implementing this feature for an enabled logical element provides support for client modification of its element name (that is, the ElementName property of the EnabledLogicalElement instance representing the element).

Implementing this feature for an enabled logical element requires that the Capabilities feature is also implemented for that element.

If this feature is implemented for an enabled logical element, the following constraints apply:

If this feature is not implemented for an enabled logical element, the following constraints apply:

This feature can be made available to clients at the granularity of EnabledLogicalElement instances.

It can be concluded that the feature is available for a EnabledLogicalElement instance if:

Otherwise, it can be concluded that the feature is not available.

Adaptations

Conventions

This profile defines operation requirements based on DSP0223.

For adaptations of ordinary classes and of associations, the requirements for operations are defined in adaptation-specific subclauses of subclause Adaptations.

For association traversal operation requirements that are specified only in the elements table of an adaptation (i.e., without operation-specific subclauses), the names of the association adaptations to be traversed are listed in the elements table.

The default initialization requirement level for property requirements is optional.

The default modification requirement level for property requirements is optional.

This profile repeats the effective values of certain Boolean qualifiers as part of property, method parameter, or method return value requirements. The following convention is established: If the name of a qualifier is listed, its effective value is True; if the qualifier name is not listed, its effective value is False. The convention is applied in the following cases:

Adaptation: EnabledLogicalElement: CIM_EnabledLogicalElement

General

Adaptation type: Ordinary class

Implementation type: Instantiated

A concrete subclass of the abstract schema class CIM_EnabledLogicalElement needs to be implemented.

Requirement level:

Mandatory
This adaptation models enabled logical elements; that is, logical elements that have a concept of enabled state associated with them.

Constraints:

OCL constraint in the context of a EnabledLogicalElement instance:

inv: if self.ElementCapabilities::Capabilities.RequestedStatesSupported->size() > 0
then self.RequestedState != 12 /* Not Applicable */
    and self.EnabledState != 5 /* Not Applicable */
else
EnabledLogicalElement: Element requirements
Element Requirement Description
Base adaptations
JobControl::CIM_ManagedElement (affected element) Mandatory See JobControl::CIM_ManagedElement (affected element).
JobControl::CIM_ManagedElement (owning element) Mandatory See JobControl::CIM_ManagedElement (owning element).
Properties
ElementName Conditional See subclause "Property: ElementName"
EnabledState Mandatory See subclause "Property: EnabledState"
RequestedState Mandatory See subclause "Property: RequestedState"
TransitioningToState Optional See subclause "Property: TransitioningToState"
AvailableRequestedStates Optional See subclause "Property: AvailableRequestedStates"
HealthState Optional See subclause "Property: HealthState"
PrimaryStatus Optional See subclause "Property: PrimaryStatus"
DetailedStatus Optional
OperatingStatus Optional
CommunicationStatus Optional See subclause "Property: CommunicationStatus"
OperationalStatus Optional See subclause "Property: OperationalStatus"
Methods
RequestStateChange( ) Conditional See subclause "Method: RequestStateChange( )"
Operations
GetInstance( ) Mandatory
ModifyInstance( ) Conditional See subclause "Operation: ModifyInstance( )"
EnumerateInstances( ) Mandatory
EnumerateInstanceNames( ) Mandatory
Associators( ) Conditional See subclause "Operation: Associators( ) for ElementCapabilities"
AssociatorNames( ) Conditional See subclause "Operation: AssociatorNames( ) for ElementCapabilities"
References( ) Conditional See subclause "Operation: References( ) for ElementCapabilities"
ReferenceNames( ) Conditional See subclause "Operation: ReferenceNames( ) for ElementCapabilities"

Property: ElementName

Requirement level:

Conditional

Condition:

The ElementNameRepresentation feature is implemented.

The value of this property shall be formatted as a free-form string of variable length (pattern “.*”).

The value of this property should be the name of the enabled logical element as it would be communicated to an end-user. The value of this property should contain an identifier that can be used by the end-user to differentiate that logical element from another logical element of the same type contained in or aggregated by the same system.

For example, if the logical element is a port on a computer system with 100 ports over subordinate systems (sub system 1 and sub system 2), then the ElementName property could have the value "port 43 on sub system 2". If the logical element were a processor on a blade system within a modular system with two processors per blade system, then the ElementName property could have the value "processor 2 on blade system 1".

Property: EnabledState

Requirement level:

Mandatory

The value of this property indicates the current enabled state of the enabled logical element, using any of the values defined in its value map (see CIM Schema).

The description of the EnabledStateRepresentation feature defines additional requirements for this property.

Specializing profiles may constrain the allowable values for this property and may define particular interpretations of those values.

When the represented enabled logical element is in transition from one state to another, the enabled state of the element may be indeterminate. Thus, if the TransitioningToState property is non-Null, does not have the value 5 (No Change) or 12 (Not Applicable) which represents a state transition in progress, the EnabledState property shall have the value 0 (Unknown).

Property: RequestedState

Requirement level:

Mandatory

The value of this property indicates the last requested enabled state of the enabled logical element (as requested through the RequestStateChange( ) method), using any of the values defined in its value map (see CIM Schema).

If the implementation cannot represent the last requested enabled state, this property shall have the value 0 (Unknown).

The description of the EnabledStateRepresentation feature defines additional requirements for this property.

Specializing profiles may constrain the allowable values for this property and may define particular interpretations of those values.

Property: TransitioningToState

Requirement level:

Optional

The description of the EnabledStateRepresentation feature defines additional requirements for this property.

Property: AvailableRequestedStates

Requirement level:

Optional

If this property is non-Null (that is, implemented), the requirements for this property depend on whether the EnabledStateManagement feature is implemented for the represented enabled logical element.

Property: HealthState

Requirement level:

Optional
The value of this property indicates the health state of the represented enabled logical element, using any of the values defined in its value map (see CIM Schema).

The value of this property needs to be consistent with non-Null values of the first array entry of the OperationalStatus property, and with non-Null values of the PrimaryStatus property, as described in .

Property: PrimaryStatus

Requirement level:

Optional
The value of this property indicates the primary condition of the represented enabled logical element, using any of the values defined in its value map (see CIM Schema).

The value of this property needs to be consistent with non-Null values of the first array entry of the OperationalStatus property, and with non-Null values of the HealthState property, as described in .

Property: CommunicationStatus

Requirement level:

Optional
The value of this property indicates the ability of the implementation to communicate with the represented enabled logical element, using any of the values defined in its value map (see CIM Schema).

The value of this property needs to be consistent with communication related values in any array entry of the OperationalStatus property, as described in .

Property: OperationalStatus

Requirement level:

Optional
The value of this property indicates the operational status of the represented enabled logical element, using any of the values defined in its value map (see CIM Schema). This property may contain values in its array entries that cover a number of different areas; the properties PrimaryStatus, DetailedStatus, OperatingStatus, and CommunicationStatus represent the same information in a more specific way and should be used in new profiles instead of OperationalStatus.

The value of the first array entry of this property (that is, OperationalStatus[0]) needs to be consistent with non-Null values of the PrimaryStatus property, and with non-Null values of the HealthState property, as described in .

Constraints:

OCL constraint in the context of a EnabledLogicalElement instance:

inv: self.OperationalStatus[0] in
{
    0 /* Unknown */,
    2 /* OK */,
    3 /* Degraded */,
    6 /* Error */
}

Explanation:

The value of the first array entry of this property (that is, OperationalStatus[0]) shall be one of the values listed in :

Allowable values for OperationalStatus[0]
OperationalStatus[0]
0 (Unkown)
2 (OK)
3 (Degraded)
6 (Error)

Method: RequestStateChange( )

Requirement level:

Conditional

Condition:

The EnabledStateManagement feature is implemented.

The requirements for this method depend on whether the EnabledStateManagement feature is implemented for the represented enabled logical element.

Invoking this method multiple times could result in earlier requests being overwritten or lost.

This method may perform its task asynchronously as part of a job that is started, or synchronously as part of the method invocation. If a job is started, the Job parameter on return references a ConcreteJob instance representing the started job. The implementation may support both or only one of these two modes of operation.

RequestStateChange( ): Parameter requirements
Parameter Description
RequestedState In, see subclause "Parameter: RequestedState"
Job Out, see subclause "Parameter: Job"
TimeoutPeriod In, see subclause "Parameter: TimeoutPeriod"
return value See subclause "Return value"
Parameter: RequestedState

Specializing profiles may constrain the allowable values for this parameter and may define particular interpretations of those values.

Parameter: Job
A (non-Null) instance path to the ConcreteJob instance representing the job, if a job was started. Null, if no job was started.

Constraints:

Referenced instances shall be of class adaptation ConcreteJob.

Parameter: TimeoutPeriod

Client-specified maximum amount of time the transition to a new state is supposed to take:

Return value

This method shall return one of the values specified in :

EnabledLogicalElement.RequestStateChange( ): Return values
Value Description
0 The state change was successfully performed and no job was started.
1 The method is not implemented.
2 An error has occurred (requirements for using this value are defined after this table).
4096 A job was started.

This method shall return the value 2 (Unknown or Unspecified Error) in any of the following cases:

Operation: ModifyInstance( )

Requirement level:

Conditional

Condition:

The ElementNameModification feature is implemented.

If the ElementNameModification feature is implemented for the represented enabled logical element, the ElementName property shall be modifiable, and this operation shall enforce the length restriction specified in the MaxElementNameLen property and the name format specified in the ElementNameMask property of the associated EnabledLogicalElementCapabilities instance.

Operation: Associators( )

Requirement level:

Conditional

Condition:

The Capabilities feature is implemented.

Operation: AssociatorNames( )

Requirement level:

Conditional

Condition:

The Capabilities feature is implemented.

Operation: References( )

Requirement level:

Conditional

Condition:

The Capabilities feature is implemented.

Operation: ReferenceNames( )

Requirement level:

Conditional

Condition:

The Capabilities feature is implemented.

Adaptation: ElementCapabilities: CIM_ElementCapabilities

General

Adaptation type: Association class

Implementation type: Instantiated

Requirement level:

Conditional

Condition:

The Capabilities feature is implemented.
This adaptation models the relationship between enabled logical elements represented by EnabledLogicalElement instances and their capabilities represented by EnabledLogicalElementCapabilities instances.
ElementCapabilities: Element requirements
Element Requirement Description
Properties
ManagedElement Mandatory Key, see subclause "Property: ManagedElement"
Capabilities Mandatory Key, see subclause "Property: Capabilities"
Operations
GetInstance( ) Mandatory
EnumerateInstances( ) Mandatory
EnumerateInstanceNames( ) Mandatory

Property: ManagedElement

Requirement level:

Mandatory

Constraints:

Property: Capabilities

Requirement level:

Mandatory

Constraints:

Adaptation: EnabledLogicalElementCapabilities: CIM_EnabledLogicalElementCapabilities

General

Adaptation type: Ordinary class

Implementation type: Instantiated

Requirement level:

Conditional

Condition:

The Capabilities feature is implemented.
This adaptation models the capabilities of enabled logical elements.
EnabledLogicalElementCapabilities: Element requirements
Element Requirement Description
Properties
InstanceID Mandatory Key
RequestedStatesSupported Optional See subclause "Property: RequestedStatesSupported"
ElementNameEditSupported Mandatory See subclause "Property: ElementNameEditSupported"
MaxElementNameLen Conditional See subclause "Property: MaxElementNameLen"
ElementNameMask Conditional See subclause "Property: ElementNameMask"
Operations
GetInstance( ) Mandatory
EnumerateInstances( ) Mandatory
EnumerateInstanceNames( ) Mandatory
Associators( ) Mandatory
AssociatorNames( ) Mandatory
References( ) Mandatory
ReferenceNames( ) Mandatory

Property: RequestedStatesSupported

Requirement level:

Optional

If this property is non-Null (that is, implemented), the requirements for this property depend on whether the EnabledStateManagement feature is implemented for the represented enabled logical element.

Specializing profiles may constrain the allowable set of values for this property.

Property: ElementNameEditSupported

Requirement level:

Mandatory

Property: MaxElementNameLen

Requirement level:

Conditional

Condition:

The ElementNameModification feature is implemented.

Property: ElementNameMask

Requirement level:

Conditional

Condition:

The ElementNameModification feature is implemented.

Adaptation: ConcreteJob: CIM_ConcreteJob

This adaptation models a job that performs the task of a method invocation asynchronously.

Adaptation type: Ordinary class

Implementation type: Embedded

Requirement level:

Defined by its embedding elements
ConcreteJob: Element requirements
Element Requirement Description
Base adaptations
JobControl::CIM_ConcreteJob Mandatory See JobControl::CIM_ConcreteJob.

Use cases and state descriptions

State description: SimpleScenario

shows an object diagram for a simple scenario with enabled logical elements conforming to this profile.

The EnabledStateManagement feature has been implemented for system1, as indicated by the fact that values are present in the RequestedStatesSupported array property of capabilities1, and per these values the system represented by system1 can be enabled, disabled and reset. The ElementNameModification feature has not been implemented for system1 (as indicated by the value False of the ElementNameEditSupported property). The system represented by system1 has been previously requested to be reset (the RequestedState property has a value of 11 (Reset)), but is currently still enabled (the EnabledState property has a value of 2 (Enabled)), with degraded status as indicated by its PrimaryStatus property, whose value is correctly derived from the value of the HealthState property.

The EnabledStateManagement feature has not been implemented for pwrsupply1. The power supply represented by pwrsupply1 is also degraded, and reports a more granular status with the DetailedStatus property.

Object diagram for the SimpleScenario state description

State description: ResetStateTransitions

This subclause describes possible state transitions during the reset of an enabled logical element that is initially in the enabled state.

Introduction and initial state

shows an object diagram with a system and a battery in its initial state. The battery1 instance representing the battery is an enabled logical element and conforms to this profile. The diagram shows only properties that are relevant for the discussion of the state transitions, so some mandatory properties are not shown.

The battery1 instance represents a battery; its EnabledState property has the value 2 (Enabled), indicating that the battery is currently enabled.

The RequestedState property has the value 0 (Unknown), indicating that the last requested state transition for battery1 is unknown.

The AvailableRequestedStates array property contains the values of the enabled states the battery can transition to, given its its current enabled state. The RequestedStatesSupported property of the capabilities1 instance advertises all the enabled states that are possible for battery1, regardless of its current enabled state.

The battery represented by battery1 is currently not in transition to any other enabled state, as indicated by the value 5 (No Change) of its TransitioningToState property. A state transition could be initiated by executing the RequestStateChange( ) method, because the EnabledStateManagement feature has been implemented for battery1. Note that a synchronous execution of the RequestStateChange( ) method requires having the state transition completed upon return of the method. As a result, the transitioning states (see and ) cannot be observed by the same client that invokes a synchronously executing RequestStateChange( ) method.

Subclauses , , , , and describe the different states that battery1 could go through after the successful execution of the RequestStateChange( ) method with the RequestedState parameter set to 11 (Reset), regardless whether the method execution is performed synchronously or asynchronously.

Note that the RequestedStatesSupported property of the capabilities1 instance does not change regardless of the current enabled state of battery1, in contrast to the AvailableRequestedStates property of the battery1 instance which changes depending on the current enabled state of battery1.

Object diagram for ResetStateTransitions: Original state

Successful reset request

shows an object diagram where battery1 has successfully received the state transitioning request to 11 (Reset) as a result of the successful execution of the RequestStateChange( ) method with the RequestedState parameter set to 11 (Reset) as indicated by the value 11 (Reset) of the RequestedState property.

The EnabledState property of battery1 still has a value of 2 (Enabled) and the TransitioningToState property still has a value of 5 (No Change), indicating that the battery is currently enabled and has not yet started the state transition.

Object diagram for ResetStateTransitions: After successful reset request

Transitioning to disabled state

shows an object diagram where battery1 is meanwhile in transition to the disabled state.

The EnabledState property of battery1 now has a value of 0 (Unknown) and the TransitioningToState property now has a value of 3 (Disabled), indicating that the battery is currently in transition to the disabled state. The AvailableRequestedStates property is an empty array indicating that the implementation does not accept any state change requests at this particular time.

Object diagram for ResetStateTransitions: Transitioning to disabled state

Transitioned to disabled state

shows an object diagram where battery1 now has transitioned to the disabled state.

The EnabledState property of battery1 now has a value of 3 (Disabled) and the TransitioningToState property now has a value of 5 (No Change), indicating that the battery is currently in the disabled state. The AvailableRequestedStates property contains the value 2 (Enabled), indicating that the implementation accepts state change requests to enable battery1 at this particular time.

Object diagram for ResetStateTransitions: Transitioned to disabled state

Transitioning to enabled state

shows an object diagram where battery1 is now in transition back to the enabled state.

The EnabledState property of battery1 now has a value of 0 (Unknown) and the TransitioningToState property now has a value of 2 (Enabled), indicating that battery1 is currently in transition to the enabled state. The AvailableRequestedStates property is an empty array, indicating that the implementation does not accept any state change requests at this particular time.

Object diagram for ResetStateTransitions: Transitioning to enabled state

Transitioned to enabled state

shows an object diagram where battery1 has arrived in its final state of the reset.

The EnabledState property of battery1 now has a value of 2 (Enabled) again and the TransitioningToState property now has a value of 5 (No Change), indicating that battery1 is currently in the enabled state. The AvailableRequestedStates property contains the values 3 (Disabled) and 11 (Reset), indicating that the implementation accepts disabling or resetting battery1 at this particular time.

Object diagram for ResetStateTransitions: Transitioned to enabled state

Use case: DetermineLevelOfStateManagement

This use case describes how a client can determine the level of state representation and state management that is supported for a particular enabled logical element.

This use case has the following preconditions:

The main flow for this use case consists of the following steps:

Use case: EnableElement

This use case describes how a client can enable a particular enabled logical element.

This use case has the following preconditions:

The main flow for this use case consists of the following steps:

Use case: DisableElement

This use case describes how a client can disable a particular enabled logical element.

This use case has the following preconditions:

The main flow for this use case consists of the following steps:

Use case: ResetElement

This use case describes how a client can reset a particular enabled logical element.

This use case has the following preconditions:

The main flow for this use case consists of the following steps:

Use case: DetermineElementNameModifiable

This use case describes how a client can determine whether client modification of the ElementName property is supported for a particular enabled logical element.

This use case has the following preconditions:

The main flow for this use case consists of the following steps:


(informative)

Change log

Change log
Version Date Description
1.0.0 2009-05-18 Published as DMTF Standard
2.0.0a 2014-01-14

Published as a Work in Progress, with the following changes:

  • Fixed the inconsistency that a central class was defined but DSP1033 was not referenced, by changing the profile type to the new profile type of "pattern profile": See DSP1001 1.2 for details on pattern profiles.
  • Fixed the issue that the ElementName property was Mandatory, by making it part of an optional feature "ElementNaming".
  • Fixed the issue that the PrimaryStatus and HealthState propertes were Mandatory, by making them Optional.
  • Added functionality to the Job output parameter of RequestStateChange() by tying it to the Job Control Profile.
  • Fixed the error in the description of method RequestStateChange() that the AvailableRequestedStates property was incorrectly attributed to class CIM_EnabledLogicalElementCapabilities.
  • Fixed the issue that the TransitioningToState property was left optional for the case that enabled state was not represented, by requiring that it is Null or 12 (Not Applicable) in this case.
  • Fixed errors in the diagrams and descriptions of the use cases and state descriptions.
  • Restricted the values of OperationalStatus[0] of EnabledLogicalElement to Unknown, OK, Degraded, and Error.
  • Established consistency requirements between the values of PrimaryStatus, HealthState and OperationalStatus[0] of EnabledLogicalElement.
  • Established consistency requirements between the values of CommunicationStatus and OperationalStatus[] of EnabledLogicalElement.
  • Converted to MRP XML format.
  • Using new generic operations names defined in DSP0223 1.0.2
Internal Error: The tocgen.js script failed (or did not run at all).