2.2 ValueTypes, Units, Dimensions & Primitive Types

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:

1. A «valueType» does not own part properties; its properties are value properties that describe data.
2. A «valueType» cannot own a state machine or execute reactive behavioral states.
3. 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

1. Visibility (Optional):
   • + : Public (default in most SysML models)
   • - : Private
   • # : Protected
   • ~ : Package
2. Name (Required): The identifier of the property (e.g., curbMass, maxOperatingAltitude).
3. Type (Required for full specification): The classifier typing the property. This must be a «valueType» or a primitive type (e.g., Mass, Real, Boolean).
4. 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.)
5. Default Value (Optional): An initial or nominal value assigned to the property, prefixed with = (e.g., = 1200.0 kg, = true, = 0.0).
6. 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

---

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

1. 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).
2. 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.
3. 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].
4. 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.