Study guide
2.2 ValueTypes, Units, Dimensions & Primitive Types
OMG Certified Systems Modeling Professional — Model User OCSMP OMG-OCSMP-MU100
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
About the OCSMP Model User (OMG-OCSMP-MU100) Exam
2 Chapter 1: SysML Overview, Diagram Framework & Model Organization
1.1 SysML Overview, MBSE Foundations & Diagram Frame Syntax 1.2 Model Organization, Packages & Viewpoints
3 Chapter 2: Block Definition Diagrams — Blocks & Structural Features
2.1 Block Definitions, Features & Compartments 2.2 ValueTypes, Units, Dimensions & Primitive Types 2.3 Specialization, Generalization & Inheritance Hierarchies
4 Chapter 3: Block Definition Diagrams — Associations, Composition & Multiplicities
3.1 Associations, Composite Aggregation & Reference Associations 3.2 Multiplicities, Reference Properties & Association Ends
5 Chapter 4: Internal Block Diagrams — Internal Structure & Interconnection
4.1 Enclosing Blocks & Part Usages 4.2 Standard Ports, Flow Ports & Interfaces 4.3 Connectors, Item Flows & Flow Specifications
6 Chapter 5: Parametric Diagrams & Constraint Modeling
5.1 Constraint Blocks, Properties & Mathematical Expressions 5.2 Parametric Diagrams & Binding Connectors
7 Chapter 6: Activity Diagrams — Control & Object Flows
6.1 Activity Diagram Anatomy & Control Nodes 6.2 Object Flow, Pins & Activity Parameter Nodes 6.3 Decision, Merge, Fork & Join Execution
8 Chapter 7: Activity Diagrams — Partitions & Action Types
7.1 Activity Partitions (Swimlanes) & Structural Allocation 7.2 Action Types: Call Behavior, Send Signal & Accept Event
9 Chapter 8: State Machine Diagrams — States, Transitions & Events
8.1 State Machine Basics: States, Regions & Orthogonality 8.2 Transitions, Trigger-Guard-Effect Syntax & State Behaviors 8.3 Event Types & Run-to-Completion Semantics
10 Chapter 9: Sequence Diagrams — Message Interactions & Lifelines
9.1 Sequence Diagram Fundamentals, Lifelines & Execution 9.2 Message Types & Interaction References (ref)
11 Chapter 10: Cross-Cutting Constructs — Allocations & Metadata
10.1 The «allocate» Dependency: Semantics & Types 10.2 Allocation Representations: Callouts, Compartments, Partitions & Tables 10.3 Comments, Rationales, Problems, Stereotypes, Frames & Diagram Descriptions
12 Chapter 11: Requirement Diagrams — Requirements Modeling & Traceability
11.1 Requirement Element Definition, ID, Text & Compartments 11.2 Key Relationships: Derive, Satisfy & Verify 11.3 Refine, Trace & Containment Hierarchies
13 Chapter 12: Use Case Diagrams — System Context & Capabilities
12.1 Actors, Use Cases & Subject Boundaries 12.2 Associations, Include, Extend & Generalization
2.2 ValueTypes, Units, Dimensions & Primitive Types
Key Takeaways Explain This Topic AI
A «valueType» defines elements that have no independent identity or lifecycle; two values with identical data are indistinguishable.
Blocks possess identity, lifecycle, and composite structure, whereas ValueTypes represent quantitative data or states without identity.
SysML 1.2's model library predefines the value types Boolean, Complex, Integer, Number, Real, and String; a value type may also own its own value properties.
In SysML 1.2, a «quantityKind» names what is measured (e.g., Length) and a «unit» names the scale (e.g., meter); a value type may reference either or both.
Value property syntax is name : Type [multiplicity] = defaultValue; a property declared without a multiplicity has the UML default of [1].
Last updated: September 2026
2.2 ValueTypes, Units, Dimensions & Primitive Types
Quick Summary: In SysML, a «valueType» represents quantifiable data or physical measurements that have no independent identity or lifecycle . This fundamentally distinguishes value types from blocks. In SysML 1.2, a value type can reference a «quantityKind» (the kind of quantity, such as Length) and a «unit» (the measurement scale, such as meter). A value property declared without a multiplicity has the UML default of [1] .
1. The Concept and Purpose of «valueType»
In systems engineering, many model elements do not represent physical hardware components or software processes with individual lifecycles. Instead, they represent quantities, measurements, coordinates, strings, or status flags. SysML addresses this with the «valueType» stereotype, which extends the UML DataType metaclass.
The Fundamental Test: Identity vs. Value
The central conceptual distinction tested on the OCSMP Model User exam between a «block» and a «valueType» is identity :
Blocks Have Identity: Two physical instances of a HydraulicActuator block may have identical part numbers, identical operating pressures, and identical dimensions, yet they are two distinct physical objects. One actuator may fail while the other continues functioning. They have unique runtime identities, unique physical locations, and distinct lifecycles.
ValueTypes Have No Identity: If two sensors report a temperature of 293.15 K , there are not two different 'instances of 293.15 K' with separate identities. The value 293.15 K is defined purely by its quantitative data. Two value elements with the same attributes are completely interchangeable and indistinguishable.
What ValueTypes Cannot Do
Because value types lack identity and lifecycle:
A «valueType» does not own part properties ; its properties are value properties that describe data.
A «valueType» cannot own a state machine or execute reactive behavioral states.
A «valueType» cannot be destroyed independently ; it exists only as the state of the property that holds it.
2. Primitive Value Types vs. Structured Value Types
SysML categorizes value types into primitive types and structured (complex) value types.
SysML Primitive Value Types Library
The SysML 1.2 model library (its Blocks package) predefines six value types: Boolean , Complex , Integer , Number , Real , and String . The four you will read most often are:
Integer : Whole numbers without fractional components (e.g., -10 , 0 , 4 , 1024 ). Used for counts, enumerations, and discrete indexing.
Real : Continuous mathematical numbers with fractional or decimal representations (e.g., 3.14159 , -0.005 , 2.998e8 ). Used for physical measurements, sensor outputs, and continuous mathematical expressions.
Boolean : Binary truth values with exactly two literals: true and false . Used for conditional flags, state guards, and logic evaluation.
String : Sequences of text characters (e.g., "Telemetry Nominal" , "FAULT_CODE_404" ). Used for names, serial identifiers, and descriptive metadata.
The other two are Number , the general numeric value type, and Complex , which holds realPart : Real and imaginaryPart : Real . SysML deliberately keeps these as mathematical concepts: Real does not fix a precision or a floating-point format.
Structured (Complex) Value Types
A value type can declare internal value properties, forming a structured value type . For example, a three-dimensional coordinate can be modeled as a single structured value type: +-----------------------------------+
- | «valueType» |
- | CartesianPoint |
- +-----------------------------------+
- | values |
- | x : Length |
- | y : Length |
- | z : Length |
- +-----------------------------------+
Other common structured value types include:
- RGBAColor (values: red : Integer , green : Integer , blue : Integer , alpha : Real )
- GPSCoordinate (values: latitude : Angle , longitude : Angle , altitude : Length )
- Complex itself, predefined by SysML 1.2 with realPart : Real and imaginaryPart : Real
Exam Key Point: Even when a value type is structured and contains multiple internal value properties, it remains an identityless value type . Two CartesianPoint instances with (x=10, y=20, z=30) are identical and interchangeable.
3. Units and Quantity Kinds in SysML 1.2
Earlier SysML versions used a «dimension» stereotype for this idea. SysML 1.2 calls it «quantityKind» and defines both «quantityKind» and «unit» as stereotypes of InstanceSpecification whose only valid use is to be referenced by a value type (or, for a quantity kind, by a unit). Annex C of the 1.2 specification adds an optional, non-normative QUDV (Quantities, Units, Dimensions, and Values) model library for building full systems of units and quantities.
«quantityKind» (Physical Observable)
A «quantityKind» represents a physical aspect or measurable phenomenon of reality, independent of any specific measurement scale or unit:
Examples: Length , Mass , Time , ThermodynamicTemperature , Velocity , Force , Pressure , ElectricCurrent .
A quantity kind does not have a numeric scale; it represents the nature of what is being measured.
«unit» (Measurement Standard)
A «unit» represents a standardized measurement scale used to quantify a specific quantityKind :
Examples for Length : meter , centimeter , inch , foot , nauticalMile .
Examples for Mass : kilogram , gram , poundMass , slug .
Examples for Velocity : meterPerSecond , kilometerPerHour , knot .
In SysML 1.2, a «unit» may reference the «quantityKind» it measures through its optional quantityKind property: «unit» meter { quantityKind = Length }
- «unit» kilometerPerHour { quantityKind = Velocity }
- Binding Units and QuantityKinds to a «valueType»
A «valueType» has two optional properties, quantityKind and unit , shown with stereotype property notation. Because a unit can already identify its quantity kind, a value type often needs to show only the unit: +---------------------------------------------------+
- | «valueType» |
- | Airspeed |
- | {quantityKind = Velocity, unit = knot} |
- +---------------------------------------------------+
When a block property is typed by Airspeed , any assigned numeric value carries the explicit semantic context of speed measured in knots.
4. Specifying Value Properties on Blocks
When a block declares a value property in its values compartment, it follows the standardized SysML text syntax: [visibility] name : Type [multiplicity] = defaultValue {modifiers}
Detailed Breakdown of Syntax Elements
Visibility (Optional):
- + : Public (default in most SysML models)
- : Private
- # : Protected
- ~ : Package
Name (Required): The identifier of the property (e.g., curbMass , maxOperatingAltitude ).
Type (Required for full specification): The classifier typing the property. This must be a «valueType» or a primitive type (e.g., Mass , Real , Boolean ).
Multiplicity (optional in notation; default [1] ):
Enclosed in square brackets, e.g., [1] , [0..1] , [1..*] , [0..*] , [*] .
Rule: If a property declaration omits the multiplicity, UML's default of [1] applies. (Association ends at a black or white diamond are different: SysML 1.2 lets you assume [0..1] there when nothing is shown. See Section 3.2.)
Default Value (Optional): An initial or nominal value assigned to the property, prefixed with = (e.g., = 1200.0 kg , = true , = 0.0 ).
Modifiers (Optional): Constraints enclosed in curly braces, such as {readOnly} , {unit = kilogram} , {ordered} , or {unique} .
Working Examples
dryMass : Mass [1] = 1450 kg {readOnly} — A single, read-only mass value with a default of 1450 kg.
payloadWeights : Mass [0..*] — An ordered or unordered collection of zero or more mass measurements.
isArmed : Boolean = false — A single boolean flag defaulting to false (multiplicity defaults to [1] ).
nominalVoltage : Voltage [1] = 28.0 V — A 28-volt nominal electrical potential property.
5. Comparison: Predefined Value Types vs. Structured Value Types vs. Blocks
- Criteria Predefined Value Type (e.g., Real ) Structured Value Type Block
- Metaclass DataType ( «valueType» ) DataType ( «valueType» ) Class ( «block» )
- Identity None None Unique runtime identity
- Lifecycle None None Independent lifecycle
- Can Own Parts? No No Yes (via composite aggregation)
- Can Own State Machines? No No Yes
Can Have Units? Not by itself; specialize it (e.g., Mass from Real ) and add a unit Yes ( unit and quantityKind properties) Indirectly (via owned value properties)
- Can Specialize? Yes Yes Yes
- Visual Representation Usually named in text (e.g., : Real ) Rectangle with «valueType» Rectangle with «block»
- 6. Worked Engineering Example: UAV Telemetry System
Consider an Unmanned Aerial Vehicle (UAV) flight computer block defined on a BDD: +---------------------------------------------------+
- | «block» |
- | UAVFlightComputer |
- +---------------------------------------------------+
- | values |
- | groundSpeed : Speed = 180 km/h |
- | barometricAltitude : Length = 2500 m |
- | attitude : EulerAngles |
- | autopilotActive : Boolean = true |
- | waypointCoordinates : GPSCoordinate [1..100] |
- +---------------------------------------------------+
groundSpeed is typed by Speed , which has quantityKind = Velocity and unit = kilometerPerHour .
barometricAltitude is typed by Length , which has quantityKind = Length and unit = meter .
attitude is typed by EulerAngles , a structured value type with values roll : Angle , pitch : Angle , and yaw : Angle .
autopilotActive is typed by the primitive type Boolean , defaulting to true with multiplicity [1] .
waypointCoordinates is a collection of 1 to 100 structured coordinates typed by GPSCoordinate .
7. Common OCSMP Exam Traps & Pitfalls
QuantityKind vs. Unit Confusion: This is among the most frequent trick questions on the exam. Questions will present choices like 'Is Kilogram a quantityKind?' or 'Is Length a unit?' . Always remember:
QuantityKind: What is being measured (Mass, Length, Velocity, Pressure).
Unit: How it is measured (Kilogram, Meter, Knot, Pascal).
The Part Property Trap: A «valueType» describes data, not an assembly, so it is not the whole in a black-diamond composition of blocks. If a diagram shows a value type owning a block as a part, treat it as a modeling error.
Multiplicity Default Trap: When a property string like velocity : Speed = 60 km/h has no brackets, examinees often assume the multiplicity is unspecified or 0..* . For a property declaration like this, UML's default multiplicity is [1] .
Identity Fallacy: Exam scenarios will describe two identical telemetry packets with identical timestamps and data values and ask if they are two distinct blocks or value types. Data values without distinct physical life are modeled as ValueTypes.