1. Using Physical Quantities in SysML

2. Motivation Need quantities for analysis Also need non-atomic values:
Also multiply number of things to get total quantities
Also need non-atomic values:
Vectors
Matrices
Scalar Fields
Vector Fields
Time-varying quantities
Want to try and use most UML-like options

3. Key Semantics to Rectify
Deal with the fact that engineering properties have quantities not values
Power is not a value, but an amount of work over an amount of time
Powers and masses don’t go together
It’s not just about units
Deal with time properly
System should be referenced to points in time when things are dynamic – there is a quantity of time between two of these points
Deal with vectors properly
Index values against a vector basis
Deal with locations in space properly
Index scalars and vector quantities against points in space
Properly treat model as constraint on use-time instances

4. Key idea from UML: Association Qualifiers
“A qualified Association end has qualifiers that partition the instances associated with an instance at that end, the qualified instance. Each partition is designated by a qualifier value, which is a tuple comprising one value for each qualifier. The multiplicities at the other ends of the association determine the number of instances in each partition. So, for example, 0..1 means there is at most one instance per qualifier value. If the lower bounds are non-zero, the qualifier values must be a finite set, for example because the qualifiers are typed by enumerations. “
Instances of quantities would be indexed by instances of time points, for example

5. No reason that number of wheels should be fundamentally different than number of meters between wheel center and edge (radius)
Dynamic properties have values indexed by time
Vector properties are also indexed by the choice of basis and vector
Units aren’t quantities – they just scale them
Quantity is like AdjunctProperty – a patch waiting for other fix

6. The “quantity binding” intends to connect the QuantityProperty / multiplicity to the value of constraint parameters
Again, this is a patch on waiting for deeper solution in UML

7. Instantiation of the block diagram for a given time trajectory might look like this – a series of time points, velocities, and vector directions.
UML specification is unclear about how to actually connect the “key” from the qualifier to the “value” of the property …

8. Velocity = (t = 0, x) -> 10. 0, (t = 1, x) -> 15
Velocity = (t = 0, x) -> 10.0, (t = 1, x) -> 15.0, (t = 2, x) -> 15.75
Should have an instance notation that works better with a functional mapping between domain and codomain instances

9. The Argument (1)
Current approach to engineering properties has a series of problems
Cannot use multiplicities of parts in equations (to get total mass, for example)
Does not make sense that one physical quantity (e.g., number of wheels) is modeled differently than another (e.g., number of atoms -> mass)
No standard way to connect the time of behaviors to computations
No vectors, matrices, scalar fields, vector fields

10. The Argument (2) Want to use existing UML semantics where possible
Connect multiplicity to physical quantity
Use qualifiers as mathematical function, e.g., property S(t) : time -> Speed quantity
May need to use SysML stereotypes to guide UML in useful directions
Other alternatives have been tried but are more kludgy; also don’t resolve quantity mismatch in multiplicity semantics
Stereotyping one ValueProperty as Key and other as Value
Making compound ValueTypes

11. Conclusion
Have an approach to physical quantities to emphasize the “physical”
Also includes features to get properties and values needed for more in-depth engineering analysis
Unfortunately requires more of the “double bookkeeping” with Stereotypes creeping into SysML