5.1 Constraint Blocks, Properties & Mathematical Expressions

5.1 Constraint Blocks, Properties & Mathematical Expressions

Quick Reference: A Constraint Block (shown with the keyword «constraint») defines an analytical equation or system of mathematical relationships using two specialized compartments: parameters (variables typed by value types) and constraints (algebraic equations enclosed in {}). In a structural model, regular blocks reuse these mathematical definitions by declaring Constraint Properties (the ConstraintProperty stereotype; on internal properties the keyword shown is «constraint»), thereby binding physical structural attributes to engineering physics.

---

The Role of Parametrics in Model-Based Systems Engineering

In traditional document-centric systems engineering workflows, analytical mathematical modeling and descriptive architectural modeling lived in completely disconnected silos. Systems architects captured system structure, component hierarchies, and behavioral sequences using drawing tools or specification documents, while performance engineers, propulsion specialists, and electrical designers modeled physics equations, mass properties, and power budgets in external spreadsheets, numerical scripts, or specialized finite element solvers.

When structural parameters changed—such as increasing a satellite payload's structural housing thickness—the updated mass value rarely propagated automatically to the thermal dissipation analysis or the orbital launch vehicle ascent model. This lack of integration created severe synchronization gaps, leading to unexpected performance shortfalls and costly late-stage redesigns.

SysML bridges this divide through its Parametrics modeling pillar. Parametrics provides a native, standardized mechanism for embedding engineering physics, performance formulas, mathematical invariants, and regulatory constraints directly into the system model. Rather than treating mathematical analysis as an external afterthought, SysML allows systems engineers to integrate equations governing mass rollups, Ohm's law, thermodynamics, orbital mechanics, and cost estimation into the descriptive architecture.

The structural definition of mathematical equations begins on Block Definition Diagrams (BDDs) through two foundational modeling elements:

1. Constraint Blocks («constraint»): The reusable definitions or templates of mathematical equations.
2. Constraint Properties: The usages or instantiations of those equations within structural system blocks.

---

Definition and Syntax of Constraint Blocks

A Constraint Block is a specialized SysML classifier that defines a set of mathematical constraints and the parameters involved in those constraints. Constraint blocks are defined on Block Definition Diagrams (BDDs) alongside standard blocks, value types, and enumerations.

Graphical Notation on a BDD

A constraint block is rendered as a standard rectangular classifier box, distinguished by the keyword «constraint» placed immediately above the classifier name in the title compartment:

+------------------------------------+
|            «constraint»            |
|               OhmLaw               |
+------------------------------------+
| parameters                         |
|   v : Voltage                      |
|   i : Current                      |
|   r : Resistance                   |
+------------------------------------+
| constraints                        |
|   {v = i * r}                      |
+------------------------------------+

The underlying stereotype is named ConstraintBlock, but SysML 1.2 says constraint blocks "must have the «constraint» keyword shown." ConstraintBlock specializes the Block stereotype, so a constraint block is a kind of block, one restricted to parameters, nested constraint properties, binding connectors, and constraint expressions.

---

Anatomy of a Constraint Block: Parameters and Constraints

A constraint block typically shows two specialized compartments that distinguish it from an ordinary block:

1. The parameters Compartment

The parameters compartment lists the variables (known formally as constraint parameters) that participate in the mathematical equations.

• Each constraint parameter is declared as an attribute using standard SysML property syntax: parameterName : Type [multiplicity]
• The type of a constraint parameter is typically a ValueType (such as Real, Integer, Voltage, Kilograms, or NewtonMeters), optionally associated with a specific unit and quantity kind.
• Multiplicities define the number of values allowed for the parameter (defaulting to [1] if omitted).
• Example parameter declarations:
  • m : Mass
  • a : Acceleration
  • F : Force

2. The constraints Compartment

The constraints compartment contains one or more formal or informal mathematical expressions that state the relationships that must hold among the constraint parameters.

• Curly Braces {} Convention: Constraint expressions use UML's text notation for a constraint: a string in braces such as {F = m * a}. A language name can be given in inner braces, as in {{OCL} x > y}. SysML 1.2 also allows informal text statements in the constraints compartment, and the same compartment can list nested constraint properties.
• Example constraint expressions:
  • {F = m * a}
  • {P = V * I}
  • {totalMass = dryMass + fuelMass + payloadMass}
  • {temperature <= maxOperatingTemp}

Constraint Expression Languages

SysML does not force modelers into a single proprietary or formal mathematical syntax. The expression within the curly braces can be written in several formalisms depending on the model's toolchain:

• Informal Mathematical Notation: Standard algebraic expressions such as {v = d / t}.
• OCL (Object Constraint Language): A formal, declarative language standardized by OMG (e.g., {self.loadCurrent <= maxSafeCurrent}).
• Mathematical Markup & Domain Languages: Expressions written in MathML, Modelica, or programming syntax.

Regardless of the syntax chosen, the expression must refer strictly to the constraint parameters defined in the parameters compartment of the constraint block or inherited from parent constraint blocks.

---

Architectural Comparison: Constraint Blocks vs. Standard Blocks

A critical topic assessed on the OCSMP Model User exam is the strict behavioral and architectural boundary between standard structural blocks and constraint blocks.

A constraint block is not a general-purpose block. It is a highly restricted, specialized classifier engineered exclusively for mathematical assertion:

---

Constraint Properties: Instantiating Equations in System Blocks

Defining a constraint block on a BDD merely creates an abstract mathematical formula. For that formula to evaluate properties of a physical system, a structural block must instantiate that formula as a Constraint Property.

What is a Constraint Property?

A Constraint Property is a structural usage of a constraint block within the context of a regular block. It indicates that the enclosing block's behavior and attributes are constrained by the mathematical equations defined in that constraint block.

Visual Representation on a BDD

There are two standard ways to depict constraint properties on a Block Definition Diagram:

1. Compartment Notation

Inside a regular block, a dedicated compartment titled constraints lists each constraint property using standard usage syntax: constraintPropertyName : ConstraintBlockType

For example, a Satellite block might declare:

+------------------------------------+
|               «block»              |
|              Satellite             |
+------------------------------------+
| values                             |
|   mass : Mass                      |
|   thrust : Force                   |
|   accel : Acceleration             |
+------------------------------------+
| constraints                        |
|   f_ma : NewtonSecondLaw           |
+------------------------------------+

2. Composite Aggregation Notation

A Block Definition Diagram can also show the relationship graphically using a composite association (solid black diamond) from the owning structural block to the constraint block.

• The black diamond sits on the owning structural block (e.g., Satellite).
• The line connects to the constraint block (NewtonSecondLaw).
• The end near the constraint block is adorned with the role name representing the constraint property (e.g., +f_ma) and optional multiplicity (e.g., 1).
• The resulting property carries the ConstraintProperty stereotype. SysML 1.2 requires composite aggregation for any block property typed by a constraint block, which is why the black diamond is used.

Type vs. Usage Distinction

Just as a standard block (like Wheel) is a type while frontLeftWheel : Wheel is a part property (usage), a ConstraintBlock (like NewtonSecondLaw) is a type while f_ma : NewtonSecondLaw is a constraint property (usage). A single constraint block can be instantiated many times across diverse structural blocks. For instance, OhmLaw can be instantiated within an AudioAmplifier block as ampOhm, within a SensorModule block as sensorOhm, and within a PowerConverter block as regulatorOhm.

---

Non-Causal Semantics and Mathematical Expressions

A foundational principle of SysML constraint modeling tested on the OCSMP examination is the non-causal (acausal) nature of constraint expressions.

Declarative Invariants vs. Imperative Assignments

In procedural software programming languages (such as C++, Java, or Python), an equation like F = m * a represents an imperative assignment statement:

• The values on the right-hand side (m and a) are evaluated.
• The resulting computed value is assigned to the variable on the left-hand side (F).
• Execution is strictly directional (inputs on right, output on left).
• You cannot write m * a = F or expect the computer to compute a = F / m without writing a separate function.

In SysML, a constraint expression is a declarative mathematical invariant:

• The expression {F = m * a} states a perpetual physical truth: the product of mass and acceleration is mathematically equal to force.
• It specifies no computational causality: F is not designated as an output, nor are m and a designated as inputs.
• An analytical engine or solver connected to the SysML model can solve for any variable given the others:
  • If m and a are known, it calculates F = m · a.
  • If F and m are known, it solves a = F / m.
  • If F and a are known, it solves m = F / a.
• Equalities and inequalities are bidirectional mathematical bounds: {stress <= yieldStrength} asserts that allowable stress must never exceed the material yield strength.

---

Exam Pitfalls & Misconceptions