BDD & IBD: Humidifier | Webel IT Australia

Firstly, note that the block WaterTank is NOT a physical block, it is merely a "computation block" for tracking the volume of water in a water tank, which information is used by the StateMachine ControlSM within block Control (namely it switches the entire system off if the water level gets too low).

Similarly, the block VaporGenerationPlant is NOT a physical block, it is a "computation block" for tracking the generation of vapor, depending on both the power of a cooling safety fan and a water heater.

Neither the fan nor the heater are explicitly modelled. There is also no explicit modelling of the provision of water from a physical water tank to a physical vapor generation plant. All that happens is that values (only) representing and tracking physical quantities are "shunted" around. It's quantity signal flow, NOT physical interaction.

Note also that there are three StateMachines UsageControlSM, ControlSM, and HeaterControlSM. We'll look at these in more detail next, but for now just note that the UsageControlSM acts as a switch across the entire system, mediated by ControlSM (which may directly influence the fan and indirectly also the heater) according to the tank's WaterVolume level and the WaterTemperature.

Using explicitly named ValueTypes to type value properties and for ItemFlows on Connectors can be extremely useful for figuring out exactly what is going on.

It's not 100% clear whether there is a physical vapor generation plant and physical heater separate from a physical water tank (such as for a large commercial humidifier), or whether the heater simply acts directly on the water tank (such as for a small domestic humidifier). It is assumed here that they are indeed physically separate.

See that Connector from oVapor Port on the vGP:VaporGenerationPlant to the iConsumption Port on the wt:WaterTank? It's not carrying physical vapor back into a water tank! It's just conveying information about the quantity VaporRate_mL_per_h (as was generated by the vapor generation plant).

We're going to start our journey through the Humidifer at WaterTank, because it helps us anchor the Units.

Up next

BDD & PD: WaterTank

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]{RECOMMENDED} Suffix the "focus" BDD for a Block with .bdd so that it won't clash with a corresponding IBD on diagram export.

[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' 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.