Binding connectors, units and constraint nesting in a rover power budget
A Mars rover model must demonstrate that its power budget closes before a design gate. Block Rover owns drill : Drill [1] and avionics : Avionics [1]; both parts have value properties mass : Mass and power : Power typed by ISO 80000 units, kg and W. The analyst builds constraint block PowerBudget with parameters totalPower : Power, dryMass : Mass, drillPower : Power and avionicsPower : Power, and a constraint stating totalPower equals drillPower plus avionicsPower. In the parametric diagram framed on Rover she places the PowerBudget definition itself and tries to draw binding connectors; the tool refuses. She then creates pb : PowerBudget inside Rover and draws three bindings: pb.dryMass to rover.avionics.mass, pb.totalPower to rover.drill.power, and pb.dryMass to rover.drill.mass. The drillPower parameter is left unbound. The evaluator runs and reports totalPower equal to 0 W with no error.
1. Why could no bindings be drawn to the constraint block, and what is the correct structure of the parametric diagram?
Read the worked answer
A constraint block is a definition; a parametric diagram binds usages. Binding connectors join value properties, and inside a constraint property the parameters are exactly that, value properties of that property. A definition has no instance whose values can be equated, so there is nothing at either end for the connector to attach to and the tool is right to refuse.
The frame of a parametric diagram is the context that owns the constraint property, typically the block whose values are constrained, here Rover, or a single constraint property when one is shown in isolation. The intended construction order is: define PowerBudget with its parameters and expression; inside Rover create pb : PowerBudget and bind, on the same diagram, Rover's parts drill and avionics with the value properties mass and power, plus pb; then draw the bindings between parameters and those value properties.
There is also a namespace rule behind the refusal: elements shown in a diagram must be owned, directly or indirectly, by the frame's context. The PowerBudget definition is owned by its package, so placing it in a diagram framed on Rover is a model error, not merely a drawing slip. A diagram is a view and cannot invent ownership. If the intent was a standalone, reusable analysis rather than a property of Rover, build a dedicated analysis block or package that owns the constraint property and references the parts, so the same budget can be applied to other rover configurations.
2. Diagnose the three bindings and the unbound drillPower. What does binding actually assert, what does binding dryMass twice mean, and would SysML catch a Mass bound to a Power parameter?
Read the worked answer
Binding is equality, not data flow; a binding connector asserts that the two ends always evaluate to the same value. That single fact explains all four symptoms.
- pb.dryMass bound to avionics.mass and to drill.mass asserts avionics.mass = dryMass = drill.mass. Two unrelated masses are forced equal, which over-constrains the model and produces a wrong answer even though nothing is dimensionally wrong. What was intended was dryMass = drill.mass + avionics.mass, which needs its own constraint, or one expression inside PowerBudget referring to both parts' masses through separate parameters.
- pb.totalPower bound to drill.power ties a computed output to an input value. Evaluators resolve in whichever direction the binding graph permits, so depending on order you either get a conflict or a trivially satisfied equation that proves nothing.
- drillPower unbound is the direct cause of the 0 W. An unbound parameter leaves the system under-determined, and evaluators commonly substitute a default or zero rather than raising an error, which is the dangerous case: a figure that looks like a result.
SysML itself does not enforce dimensional consistency. Value types carry unit and dimension precisely so tools can check, but a semantic error such as binding a Mass to a Power parameter may be reported by a tool as a unit mismatch and may equally be silently coerced. Fix by one binding per equality you mean, exactly one determining relation per computed parameter, every parameter bound before evaluation, and a manual sanity check of the result against the gate criterion rather than trusting the absence of errors.
3. The chief engineer wants one hierarchical budget instead of separate diagrams per subsystem. Explain how nested constraint properties work, where shared quantities should be bound, and the specific failure mode to avoid.
Read the worked answer
Composite constraint properties let you build a budget hierarchy: a constraint property whole : WholeBudget whose type owns, in turn, pb : PowerBudget and mb : MassBudget, each with its own parameters. The nested properties are genuine parts of the outer constraint property, so bindings can cross levels: an inner parameter may be bound directly to a value property of rover.drill, or to a parameter of the outer constraint property.
The cleaner pattern is to expose the shared quantity once at the boundary. Bind pb.totalPower to whole.totalPower, then bind whole.totalPower once to the block value that actually carries the requirement, or leave it free when the total is the quantity being computed. Bind the inner parameters that belong to specific parts, drillPower and avionicsPower, straight to the corresponding part properties. Each level then talks only to its own boundary, the composite is reusable across rover variants whose parts differ, and the diagram stays readable at one level of detail per frame.
The failure mode to avoid is the double binding: an inner parameter bound upward to its parent and downward to a part, or two inner parameters both bound to the same external value. Both are legal equality assertions, so no tool rejects them, yet they silently equate two quantities that were meant to be independent, exactly as the dryMass error did. Before closing the gate, count bindings per parameter: every parameter should have exactly one, except deliberately shared boundary parameters, which should be bound once and reused by reference through the hierarchy.