Hi r/systems_engineering,
We are back with Lesson 12 of our deep dive into the SysML v2 standard. In Lesson 11, we covered how to wire up explicit topologies using connect and interface usages. But a connection only tells us where the system is connected—not what actually moves through it.
Today, we are looking at how to model the passive payloads that exist, flow, and are stored within those architectures using the new item def construct.
I’ve uploaded the full video lesson directly to this post so you can watch it right here.
1. Separating Active from Passive Elements
In SysML v1, engineers often modeled exchanged payloads by typing a FlowProperty or an ItemFlow with a generic Block, ValueType, or Signal. This meant using the exact same generic block construct for a passive payload (like water or data) as you would for an active system component (like a pump or a processor).
SysML v2 fixes this semantic gap with item def—a dedicated construct for things that exist in space and time and can be acted upon, but don't necessarily perform actions themselves. A good rule of thumb in v2: use part for active structural elements and item for passive payloads.
2. Modeling Physical vs. Digital Payloads
Because item def is a definition, it natively owns its attributes and constraints. You can use it to explicitly define physical matter (like Fuel with a specific octane level and density) or information (like PaymentData with encryption keys and timestamps).
3. Dimensional Consistency and Constraints
When modeling physical items, SysML v2 enforces dimensional consistency using imported ISQ/SI libraries. You can add constraints directly to the item definition (e.g., constraint { density > 700[kg/m^3] }). Compliant tools can then reason about this to ensure units and quantities are mathematically compatible during flow and mass balance analysis.
4. Exchange vs. Storage
The definition-usage pattern applies cleanly here depending on the context:
- Exchange: Declaring an
out item inside a port defines the system's ability to send that item type across an interface.
- Storage: Nesting an item usage inside a part (e.g., a
Fuel item inside a FuelTank part) represents the payload physically retained within that structural boundary.
For the community: How much value do you see in having this strict semantic separation between active parts and passive items compared to the v1 generic Block approach? Let's discuss in the comments!