5.2 Parametric Diagrams & Binding Connectors

5.2 Parametric Diagrams & Binding Connectors

Quick Reference: A Parametric Diagram (mnemonic: par) is a specialized variant of an Internal Block Diagram (ibd) that models networks of mathematical relationships. It visualizes Constraint Properties (drawn as rounded rectangles) and usually shows their Constraint Parameters as small squares on their borders. This guide calls those squares parameter "pins" for short; they are not activity pins. Binding Connectors, labeled «equal» in the SysML 1.2 notation table, connect those parameters to structural Value Properties, creating an integrated, non-causal mathematical network for systems analysis and requirement verification.

---

Anatomy and Purpose of Parametric Diagrams (par)

While Block Definition Diagrams (BDDs) define constraint blocks and declare constraint properties, they do not illustrate how mathematical parameters connect to specific physical attributes. That vital role belongs to the Parametric Diagram (par).

A Parametric Diagram is a specialized internal structure diagram. Unlike an Internal Block Diagram (ibd), which emphasizes the physical and logical composition of parts, ports, and connector flows, a Parametric Diagram focuses exclusively on mathematical equations, numerical parameters, and value bindings.

SysML 1.2 makes this restriction explicit: on a parametric diagram "the only connectors that may be shown are binding connectors connected to constraint parameters on at least one end," and every property shown (other than the constraint properties) must be bound to a constraint parameter, either directly or through a property it contains.

Key Engineering Benefits of Parametric Diagrams

1. Engineering Analysis Integration: Parametric diagrams serve as the formal interface between the system architectural model and external multidisciplinary analysis tools (e.g., thermal solvers, structural FEA, spreadsheet trade studies, aerodynamic simulators).
2. Automated Requirement Verification: By binding physical value properties (e.g., actualSatelliteMass) through mass rollup equations to requirement constraint thresholds (e.g., maxLaunchMass = 1200 kg), engineers can continuously evaluate whether the evolving design complies with customer requirements.
3. Trade Study Execution: Parametric networks enable automated parametric sweeps: varying one design parameter (such as solar panel surface area) immediately recalculates dependent parameters (such as electrical power output, satellite mass, and thermal dissipation).

---

Diagram Frame Header Syntax and Context Elements

Like all SysML diagrams, a Parametric Diagram must be enclosed within a standard rectangular outer frame border containing a standardized header in the upper-left corner:

kind [type] name [diagramName]

For a Parametric Diagram, the specific header elements adhere to strict rules:

• kind: Must be the 3-letter lowercase mnemonic par.
• [type]: The enclosing context classifier metaclass enclosed in square brackets. In standard SysML, this must be either [Block] (the most common context) or [ConstraintBlock].
• name: The specific name of the context Block or Constraint Block that owns the parametric model (e.g., ElectricVehicle).
• [diagramName]: An optional, user-defined descriptive label describing the analytical scope (e.g., [Stopping Distance Analysis]).

Example Valid Headers

• par [Block] UnmannedAerialVehicle [Range & Endurance Calculations]
• par [Block] ThermalControlSubsystem [Heat Rejection Budget]
• par [ConstraintBlock] AerodynamicDragLaw [Internal Parametric Decomposition]

Exam Rule: A Parametric Diagram cannot have a [Package] or [Model] as its context element in its header. Just like an ibd, a par requires a structural classifier (a Block or ConstraintBlock) to provide the namespace for the internal value properties and constraint properties being wired together.

---

Graphical Notations on a Parametric Diagram

A Parametric Diagram utilizes four primary graphical modeling elements inside its canvas:

1. Constraint Properties

Inside the diagram frame, constraint properties (the usages of constraint blocks) are rendered as rounded rectangles (rectangles with rounded corners) or standard rectangles marked with the keyword «constraint» (SysML 1.2 uses only this shorthand keyword on internal properties).

• The label inside the rounded rectangle shows the usage name and the constraint block type: propertyName : ConstraintBlockType
• Modeler convenience: The mathematical equation from the constraint block's constraints compartment is frequently displayed inside curly braces {} within the body of the rounded rectangle (e.g., {KE = 0.5 * m * v^2}).

2. Parameter Pins

The constraint parameters defined within the constraint block's parameters compartment are displayed as small square pins placed directly on the perimeter (border) of the constraint property rounded rectangle.

• Each pin is labeled with the parameter name (e.g., m, v, KE).
• Parameter pins act as the electrical-style terminals or binding endpoints of the mathematical equation.
• Pins are usually drawn flush with the border. SysML 1.2 calls this placement "purely for notational convenience" with "no semantic significance," and parameters may also be listed inside the box as x: Real.

3. Value Properties

The physical and architectural variables being constrained are depicted as standard property rectangles representing the value properties of the enclosing context block or nested parts.

• Value properties can belong directly to the enclosing context block (e.g., grossMass : Mass) or can be nested properties within parts (e.g., engine.dryMass or drawn as a property box inside a part property box).
• Value properties display their name, type, and current default or evaluated value.

4. Frame Value Properties and Parameter Pins

If a value property belongs to the enclosing context block, it may be depicted as:

• A standalone rectangle inside the diagram canvas.
• A small box or label placed directly on the interior border of the diagram frame.
• If the enclosing context element is a ConstraintBlock, the frame itself represents that constraint block, and its own constraint parameters appear as pins on the frame border.

---

Binding Connectors: Syntax and Semantics

The fundamental connective tissue of a Parametric Diagram is the Binding Connector.

Notation and Appearance

• A binding connector is rendered as a solid line between two endpoints.
• The SysML 1.2 notation table shows a binding connector with the keyword «equal». Because every connector on a parametric diagram is a binding connector, books and tools often draw them as plain lines without the keyword.
• Unlike other connectors, a binding connector is not typed by an association.
• NEVER Arrowheads: Binding connectors never have arrowheads. Arrowheads in SysML designate flow (Item Flows, Control Flows, Object Flows) or directed relationships (Dependencies, Associations). A binding connector represents static equality, not directed movement.

Semantic Rules of Binding Connectors

1. Mathematical Identity (x = y): A binding connector forces the two bound elements to hold the exact same value at all times. If value property A is bound to parameter pin x, then mathematically A ≡ x.
2. Type Compatibility: The two endpoints of a binding connector must have compatible types. For instance, a parameter pin typed by Velocity cannot be bound to a value property typed by Temperature without causing a type-conformance violation.
3. Valid Connection Topologies:
   • Parameter Pin to Value Property: Binds an engineering attribute of a structural block to a variable in an analytical equation.
   • Parameter Pin to Parameter Pin: Directly connects an output/variable of one constraint property to a variable of another constraint property, creating a chained sequence of equations without requiring an intermediate structural property.
   • Parameter Pin to Frame Parameter: Connects an internal parameter pin to a parameter of the enclosing context constraint block.

---

Non-Causal Semantics in Parametric Diagrams

The most crucial conceptual hurdle tested on the OMG-OCSMP-MU100 examination is the acausal (non-causal) execution semantics of SysML parametrics.

Why Binding Connectors Lack Direction

In block diagrams used in classical control theory or simulation software (such as Simulink), blocks have explicit input arrows and output arrows. Signal values flow in a strict, predefined chronological direction from left to right.

In SysML Parametrics:

• An equation such as {KE = 0.5 * m * v^2} does not establish KE as an output and m and v as inputs.
• The binding connectors between pins and value properties are undirected solid lines.
• Multidirectional Solving: Depending on which variables are fixed by engineering requirements or sensor measurements, an external solver can evaluate the network in any direction:
  • Forward Evaluation (Sizing): Given vehicleMass = 1500 kg and speed = 25 m/s, the solver computes KE = 468,750 J. Chained through workCalc, if brakingForce = 7500 N, it solves for stoppingDist = 62.5 m.
  • Reverse Evaluation (Requirement Verification): Given a regulatory constraint that stoppingDist <= 50 m at speed = 25 m/s with vehicleMass = 1500 kg, the solver works backward through both equations to compute the minimum required brakingForce = 9375 N.

SysML models the pure algebraic truth; the computational causality is determined by the solver at execution time based on known boundary conditions.

---

Comprehensive Worked Example: Aircraft Cruise Performance

Consider an aircraft systems engineering team modeling the steady-level cruise performance of a commercial transport aircraft.

Structural Context Block: Aircraft

The enclosing block Aircraft defines six value properties:

• mass : Mass = 75000 kg
• airspeed : Velocity = 240 m/s
• wingArea : Area = 125 m^2
• liftCoefficient : Real = 0.45
• airDensity : Density = 0.38 kg/m^3
• requiredLift : Force

Constraint Blocks Defined on a BDD

1. WeightLaw («constraint»):
   • Parameters: m : Mass, g : Acceleration, w : Force
   • Constraint: {w = m * g}
2. AerodynamicLiftLaw («constraint»):
   • Parameters: rho : Density, v : Velocity, s : Area, cl : Real, l : Force
   • Constraint: {l = 0.5 * rho * (v^2) * s * cl}
3. SteadyLevelFlightEquilibrium («constraint»):
   • Parameters: w : Force, l : Force
   • Constraint: {w = l}

Assembly on the Parametric Diagram par [Block] Aircraft [Cruise Lift Equilibrium]

Inside the diagram:

1. weightCalc : WeightLaw has pins m, g, w.
   • Aircraft.mass is bound to weightCalc.m.
   • A constant value property gravity = 9.81 m/s^2 is bound to weightCalc.g.
2. liftCalc : AerodynamicLiftLaw has pins rho, v, s, cl, l.
   • Aircraft.airDensity is bound to liftCalc.rho.
   • Aircraft.airspeed is bound to liftCalc.v.
   • Aircraft.wingArea is bound to liftCalc.s.
   • Aircraft.liftCoefficient is bound to liftCalc.cl.
   • Aircraft.requiredLift is bound to liftCalc.l.
3. equilibrium : SteadyLevelFlightEquilibrium has pins w and l.
   • Pin weightCalc.w is directly bound to pin equilibrium.w via a binding connector.
   • Pin liftCalc.l is directly bound to pin equilibrium.l via a binding connector.

This network forms a closed analytical loop. An engineer can verify whether the chosen wing area and cruise speed generate sufficient lift to counteract gravitational weight at high altitudes, all within the architectural SysML model.

With the numbers shown, the loop does not balance. Weight = 75,000 × 9.81 = 735,750 N, while lift = 0.5 × 0.38 × 240² × 125 × 0.45 = 615,600 N. A solver would report that equilibrium is violated at these values. Holding the other values fixed, steady level flight would need a lift coefficient of about 735,750 ÷ 1,368,000 ≈ 0.54.

---

Summary of Parametric Diagram Elements and Rules

---

Exam Pitfalls & Misconceptions