1 karl 1.1 // ===================================================================
2 // Title: Physical Card 2.7
3 // Filename: Physical27_Card.mof
4 // Version: 2.7.1
5 // Release: Preliminary
6 // Date: November 12 2002
7 // ===================================================================
8 // Copyright 2002 Distributed Management Task Force, Inc. (DMTF).
9 // All rights reserved.
10 // DMTF is a not-for-profit association of industry members dedicated
11 // to promoting enterprise and systems management and interoperability.
12 // DMTF specifications and documents may be reproduced for uses
13 // consistent with this purpose by members and non-members,
14 // provided that correct attribution is given.
15 // As DMTF specifications may be revised from time to time,
16 // the particular version and release date should always be noted.
17 //
18 // Implementation of certain elements of this standard or proposed
19 // standard may be subject to third party patent rights, including
20 // provisional patent rights (herein "patent rights"). DMTF makes
21 // no representations to users of the standard as to the existence
22 karl 1.1 // of such rights, and is not responsible to recognize, disclose, or
23 // identify any or all such third party patent right, owners or
24 // claimants, nor for any incomplete or inaccurate identification or
25 // disclosure of such rights, owners or claimants. DMTF shall have no
26 // liability to any party, in any manner or circumstance, under any
27 // legal theory whatsoever, for failure to recognize, disclose, or
28 // identify any such third party patent rights, or for such party's
29 // reliance on the standard or incorporation thereof in its product,
30 // protocols or testing procedures. DMTF shall have no liability to
31 // any party implementing such standard, whether such implementation
32 // is foreseeable or not, nor to any patent owner or claimant, and shall
33 // have no liability or responsibility for costs or losses incurred if
34 // a standard is withdrawn or modified after publication, and shall be
35 // indemnified and held harmless by any party implementing the
36 // standard from any and all claims of infringement by a patent owner
37 // for such implementations.
38 //
39 // For information about patents held by third-parties which have
40 // notified the DMTF that, in their opinion, such patent may relate to
41 // or impact implementations of DMTF standards, visit
42 // http://www.dmtf.org/about/policies/disclosures.php.
43 karl 1.1 // ===================================================================
44 // Description: The Physical Model defines modeling concepts related
45 // to actual boxes and packaging. This file defines the
46 // concepts related to packaging of Cards.
47 //
48 // The object classes below are listed in an order that
49 // avoids forward references. Required objects, defined
50 // by other working groups, are omitted.
51 // ==================================================================
52 // Change Log for v2.7.1
53 // CR920 - Move the CIM_Card related classes to a Physical27_Card MOF
54 // from Physical27_Package and Physical27_Connector
55 // ==================================================================
56
57 #pragma locale ("en_US")
58
59
60 // ==================================================================
61 // Card
62 // ==================================================================
63 [Version ("2.6.0"), Description (
64 karl 1.1 "The Card class represents a type of physical container that "
65 "can be plugged into another Card or HostingBoard, or is "
66 "itself a HostingBoard/Motherboard in a Chassis. The CIM_Card "
67 "class includes any package capable of carrying signals and "
68 "providing a mounting point for PhysicalComponents, such as "
69 "Chips, or other PhysicalPackages, such as other Cards.") ]
70 class CIM_Card : CIM_PhysicalPackage {
71
72 [Description (
73 "Boolean indicating that this Card is a Motherboard or, "
74 "more generically, a baseboard in a Chassis.") ]
75 boolean HostingBoard;
76
77 [Description (
78 "SlotLayout is a free-form string that describes the "
79 "slot positioning, typical usage, restrictions, individual "
80 "slot spacings or any other pertinent information for the "
81 "slots on a Card.") ]
82 string SlotLayout;
83
84 [Description (
85 karl 1.1 "Boolean indicating that at least one daughterboard or "
86 "auxiliary Card is required in order to function properly.") ]
87 boolean RequiresDaughterBoard;
88
89 [Description ("Boolean indicating that this Card is physically "
90 "unique from other Cards of the same type and therefore "
91 "requires a special Slot. For example, a double-wide Card "
92 "requires two Slots. Another example is where a certain Card "
93 "may be used for the same general function as other Cards but "
94 "requires a special Slot (e.g., extra long), whereas the "
95 "other Cards can be placed in any available Slot. "
96 "If set to TRUE, then the corresponding property, "
97 "RequirementsDescription, should specify the nature of the "
98 "uniqueness or purpose of the Card."),
99 ModelCorrespondence{"CIM_Card.RequirementsDescription"} ]
100 boolean SpecialRequirements;
101
102 [Description ("A free-form string describing the way(s) in which "
103 "this Card is physically unique from other Cards. This "
104 "property only has meaning when the corresponding boolean "
105 "property, SpecialRequirements, is set to TRUE."),
106 karl 1.1 ModelCorrespondence{"CIM_Card.SpecialRequirements"} ]
107 string RequirementsDescription;
108
109 [Description ("Operating voltages required by the Card."),
110 Units("MilliVolts") ]
111 sint16 OperatingVoltages[];
112
113 [Description (
114 "This method manipulates the power to a PhysicalConnector on "
115 "a Card. It is intended to be used by a Card (especially by a "
116 "motherboard - i.e., HostingBoard=TRUE) to turn the power on "
117 "and off for a specific PhysicalConnector located on it. For "
118 "example, in a personal computer, a system slot does not know "
119 "how to turn itself on and off. However, the motherboard "
120 "hosting this slot may have that capability. This is important "
121 "in order to support hot swapping of an adapter card in a "
122 "system slot. The method should return 0 if successful, 1 if "
123 "the request is not supported, and some other value if any "
124 "other error occurred. In a subclass, the set of possible "
125 "return codes could be specified, using a ValueMap qualifier "
126 "on the method. The strings to which the ValueMap contents are "
127 karl 1.1 "'translated' may also be specified in the subclass as a "
128 "Values array qualifier.") ]
129 uint32 ConnectorPower(
130 [IN]
131 CIM_PhysicalConnector REF Connector,
132 [IN]
133 boolean PoweredOn);
134 };
135
136
137 // ==================================================================
138 // SystemBusCard
139 // ==================================================================
140 [Version ("2.7.0"), Description (
141 "The SystemBusCard class represents additional information "
142 "for a CIM_Card, detailing the Card's bus type and data width. "
143 "These properties dictate the type of Slot into which the Card "
144 "can be inserted. For example, using the properties of this "
145 "class, one can define that a Card is a PCI, 64 bit adapter.") ]
146 class CIM_SystemBusCard : CIM_Card {
147
148 karl 1.1 [Description (
149 "An enumerated integer describing the System bus type for "
150 "this Card. It indicates the type of Slot into which the "
151 "Card can plug. The list of permissible values aligns with "
152 "the System bus types in CIM_PhysicalConnector.Connector"
153 "Type."),
154 ValueMap {"43", "44", "45", "46", "47", "48", "49", "50",
155 "52",
156 "64", "65",
157 "73", "74", "75", "76", "77", "78", "79",
158 "80", "81", "82", "83", "84", "85", "86", "87",
159 "98", "99",
160 "100", "101", "102", "103", "104", "105", "106",
161 "109", "110", "111"},
162 Values {
163 // 43
164 "PCI", "ISA", "EISA", "VESA", "PCMCIA",
165 "PCMCIA Type I", "PCMCIA Type II", "PCMCIA Type III",
166 // 52
167 "CardBus",
168 // 64
169 karl 1.1 "Access.bus", "NuBus",
170 // 73
171 "AGP", "VME Bus", "VME64", "Proprietary",
172 "Proprietary Processor Card Slot",
173 "Proprietary Memory Card Slot",
174 "Proprietary I/O Riser Slot",
175 // 80
176 "PCI-66MHZ", "AGP2X", "AGP4X", "PC-98", "PC-98-Hireso",
177 "PC-H98", "PC-98Note", "PC-98Full",
178 // 98
179 "PCI-X", "Sbus IEEE 1396-1993 32 bit",
180 // 100
181 "Sbus IEEE 1396-1993 64 bit", "MCA", "GIO", "XIO",
182 "HIO", "NGIO", "PMC",
183 // 109
184 "Future I/O", "InfiniBand", "AGP8X"},
185 ModelCorrespondence {"CIM_PhysicalConnector.ConnectorType"} ]
186 uint16 BusType;
187
188 [Description (
189 "System bus width (in bits) required by this Card. If "
190 karl 1.1 "'unknown', enter 0. If 'other' than the values, 8, 16, "
191 "32, 64 or 128, enter 1. The list of permissible values "
192 "aligns with the data in CIM_Slot.MaxBusWidth."),
193 Units ("Bits"),
194 ValueMap {"0", "1", "8", "16", "32", "64", "128"},
195 ModelCorrespondence {"CIM_Slot.MaxBusWidth"} ]
196 uint16 BusWidth;
197 };
198
199
200 // ==================================================================
201 // CardOnCard
202 // ==================================================================
203 [Association, Aggregation, Version ("2.6.0"), Description (
204 "Cards may be plugged into Motherboards/baseboards, are "
205 "daughtercards of an adapter, or support special Card-like "
206 "modules. These relationships are described by the CardOnCard "
207 "association.") ]
208 class CIM_CardOnCard : CIM_Container {
209
210 [Override ("GroupComponent"), Aggregate, Max (1), Description (
211 karl 1.1 "The Card that hosts another Card.") ]
212 CIM_Card REF GroupComponent;
213
214 [Override ("PartComponent"), Description (
215 "The Card that is plugged into or otherwise mounted on "
216 "another Card.") ]
217 CIM_Card REF PartComponent;
218
219 [Description (
220 "A string describing and identifying how the Card is "
221 "mounted on or plugged into the 'other' Card. Slot "
222 "information could be included in this field and may be "
223 "sufficient for certain management purposes. If so, "
224 "this avoids creating instantiations of Connector/Slot "
225 "objects just to model the relationship of Cards to "
226 "HostingBoards or other adapters. On the other hand, "
227 "if Slot and Connector information is available, this "
228 "field could be used to provide more detailed mounting "
229 "or slot insertion data.") ]
230 string MountOrSlotDescription;
231 };
232 karl 1.1
233
234 // ==================================================================
235 // CardInSlot
236 // ==================================================================
237 [Association, Version ("2.6.0"), Description (
238 "Slots are special types of Connectors into which adapter "
239 "Cards are inserted. This relationship of a Card in a Slot "
240 "is made explicit using the CardInSlot association."),
241 MappingStrings {"MIF.DMTF|System Slot|005.4"} ]
242 class CIM_CardInSlot : CIM_PackageInSlot {
243
244 [Override ("Antecedent"), Description (
245 "The Slot into which the Card is inserted.") ]
246 CIM_Slot REF Antecedent;
247
248 [Override ("Dependent"), Max (1), Description (
249 "The Card in the Slot.") ]
250 CIM_Card REF Dependent;
251 };
252
253 karl 1.1
254 // ===================================================================
255 // end of file
256 // ===================================================================
|