As we saw earlier, the fan power ratio is either 1.0 (on) or off (0.0), as determined via the input Port iWaterFanPower. Note that even when the fan is completely off there is some radiation (and it turns out the intrinsic radiationFactor for this is equal in strength 0.1 to the fanEfficiency).

Through dimensional analysis it was determined that:

Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "radiation" is a rate (equivalent to a power).

This implies the explicit ValueTypes RadiationFactor and FanEfficiency have units J/(K⋅s).

It seems the radiation rate is proportional to the difference between the water temperature (as received via the iWaterTemperature Port from the Heating computation block) and the roomTemperature.

BTW: This is yet another example of where the Single Source of Truth (SSOT) and Don't Repeat Yourself (DRY) policies are broken, because the roomTemperature here and the roomTemperature under block VaporPressureCalculation would seem to be the same (30 °C), so SHOULD be shared via some common system-wide block!

Although the full physical setup of the system is not described in the spec example, it seems that the radiating water is somehow interacting with the room environment. (Later we'll see that the WaterTank seems to be exposed also to a lower environmental temperature of 20 °C.)

Up next

BDD & PD: VaporGenerationPlantCalculation

Notes

[ASSERTION] Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "radiation" is a rate (equivalent to a power).

[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!