BDD: Figure 60: Hydraulics blocks, ports, & component properties

Gallery
Tutorial
An expanded version of the spec's Block Definition Diagram (BDD) Figure 60: Hydraulics blocks, ports, & component properties:
Click on the image to view it full size

There is an error in the spec model: On attempted validation get:
'The model has 6 variables and 7 equations.'
Even though 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.

This is a nice expert tool tip:

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:

Unless one tank is on the surface of the Earth and the other is on Neptune the value of 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.)

Up next
Notes
Snippets (quotes/extracts)
Visit also
Visit also (backlinks)
Related slides (includes other tutorials)
Related slides (backlinks, includes other tutorials)