Tags and keywords
This is one of the more interesting of all of the SysMLv2 PILOT examples as concerns options for use of SysMLv2 (which is a language of systems engineering "building blocks") for classic functional analysis breakdown in systems engineering, and warrants a wider discussion.
The sample employs one way of combining SysMLv2 performed actions with SysMLv2 allocations, and serves to illustrate the following challenge:
Recall also:
What that means here is that (although one could) it's NOT a good idea to contrive a SysMLv2 allocation definition for the relationship between the action within the part torqueGenerator and generateTorque within providePower; in SysMLv2, that's what performed actions do for us so nicely.
[As a side note, in many systems engineering methodologies (the sample is of course simplified) the «action» providePower and the «part» generateTorque ("logical" component) would live in separate packages and belong to separate "sub-layers" of the "logical" zone (or problem statement space). It suffices for the discussion here to say that both are within the "logical" zone represented by the package LogicalModel]
The «perform» providePower.generateTorque is then allocated to a corresponding «perform» within the "physical" model. So the "physical" engine part within the part powerTrain now ALSO performs generateTorque!
The SysMLv2 GitHub example shows a natural fit for SysMLv2 allocations, but it would be nice to resolve the "double performed" matter somehow for improved traceability. One could, for example, use custom Metadata to distinguish the 2nd «perform» in the "physical" zone from the 1st «perform» in the "logical" zone. That could then also be used in query view tables.
Alternatively, using a slightly less direct approach, we could annotate the part in the "physical" as «#physical» (using SysMLv2 user keywords) and then in a query view table we cold see that the owner of the 2nd «perform» is has that metadata annotation.