Tags and keywords
There is an error in the spec model: On attempted validation get:
resistance:ViscousResistance
is effectively a constant (as it is always computed from values that don't change with time) it is in fact handled like a variable via a Constraint (as we'll see also later ):
{resistance=(8*viscosity*length)/(3.1416*(radius^4))}
Some minor diagramming differences compared with the spec figure version:
- SysML Ports are used (instead of Association ends with composite aggregation and a user-defined «port» keyword).
- The context block ConnectedTanks
is shown.
It's done here so one can see the assignment of the InstanceSpecifications that carry the initial values for the components in the context of ConnectedTanks
. Each InstanceSpecification is set as the defaultValue
of a corresponding Property of ConnectedTanks
; the values their Slots carry then become so-called initial values (a.k.a. context-specific values) for the corresponding value properties within the context block ConnectedTanks
(as can be seen its IBD).
But this trail model handles some of the initial values differently, because the example as shown in the spec breaks the Single Source of Truth (SSOT) and Don't Repeat Yourself (DRY) principles:
gravity
should probably always be the same for both Tank usages!
This might not matter for a spec example, but it does matter on real-world engineering projects!
Therefore, to show you how to get more reuse, in this trail version a direct defaultValue
is declared on the value properties gravity
(and similarly on fluidDensity
) on the block Tank; only fluidLevel
(which could definitely be initially different for each Tank usage) and tankSurfaceArea
(which could potentially be different for each Tank usage) are handled using the additional Context-Specific Values mechanism.
(One could of course take this approach further and isolated gravity
in a block of EarthSurfaceConstants
, then assign that EarthSurfaceConstants::gravity
as the defaultValue
on gravity
in an assumed earth-bound Tank.)
As indicated, there are a lot of additional user-defined ValueTypes and Units in this example that aren't available directly in the specified non-normative SysPhSLibrary ModelLibrary. (Some of them could of course also have been fetched from the ISO-80000 ModelLibrary.)