BDD & PD: SaturationVaporPressure

First, a little Webel whinge about the spec model breaking the Single Source of Truth (SSOT) and Don't Repeat Yourself (DRY) principles. The values of both the celciusOffset (a physics constant) and roomTemperature (a system test constant) on the redefining scenario block SaturationVaporPressure_S1 are reused elsewhere in the system and SHOULD therefore be shared via a common block.

Some quick dimensional analysis reveals that parameter c1 on SaturationVaporPressureConstraint and the bound p1 on SaturationVaporPressure must be pressures, apparently given in hectopascals (hPa).

There are no inputs, so the output via Port oSatVaporPressure is effectively a constant for any run for a given roomTemperature, and seems to be in pascals (Pa), which we'll need to know for the dimensional analysis elsewhere.

Up next

BDD & IBD: RelativeHumidity

Notes

[ASSERTION]{STRONG} Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "vapor" is a volume rate corresponding to the rate of consumption OF HEATED LIQUID WATER (from a tank) used to create the vapor.

[MODELLING, NAVIGATION, PATTERN, TIP, TOOL]{STRONG} Webel: UML/SysML: Navigation: ALWAYS offer a way out of a diagram (usually up a hierarchy, but possibly across) using a navigable symbol (linked to a diagram) and/or a diagram symbol. Avoid "cul-de-sacs"! [But beware of shared package cross-dependencies]

[MODELLING, PATTERN, TIP]{RECOMMENDED} SysML: When using Property::defaultValue and Property::redefinedValue to carry a "shadow hierarchy" of redefinitions across an entire system hierarchy, considering using a user-defined keyword such as «configuration» or «scenario» on each redefining Block

[CAPABILITY, FEATURE, TOOL] MagicDraw/Cameo: Supports embedding of one or more Diagrams in another via the Diagram Overview feature. Awesome!

[CONVENTION, DISPLAY, MODELLING, STYLE, TIP]{STRONG} Webel: SysMLv1: Highly recommend creating a "focus" Block Definition Diagram (BDD) for each main Block with expanded feature details and relationships to at least nearest neighbours

[NAMING, TIP]{OPTION} Optionally suffix the "focus" BDD for a Block with '.bdd' so that it won't clash with a corresponding IBD on diagram export. This is not a SysMLv1 concern, it is purely a workflow concern. It has the slight disadvantage that BDD may "indicated" twice.

[DISPLAY, STYLE, TIP, TOOL]{SUGGESTED} Style: use line width 2 or 3 on the border of the "focus" element in "focus" diagrams (such as the main Block or Class of a dedicated Block Definition Diagram or Class Diagram)

[CONVENTION, MODELLING, NAMING, TIP]{STRONG} Webel: If you must name your Ports or Pins, name them simply 'i', 'o', or 'io' (or 'oi') to indicate direction UNLESS you have to indicate a special role like 'iRole', 'oAuxiliary'. DO NOT use Port or Pin names like 'input', 'output', etc.

[CAPABILITY, FEATURE, STYLE, TIP]{RECOMMENDED} TIP: UML/SysML: MagicDraw/Cameo: Consider showing the constraint parameter name and type label inside the small rectangular parameter symbol on SysML Parametric Diagrams. Dr Darren swears by it!