BDD & PD: VaporGenerationPlantCalculation

The energy available for heating the water - and then transforming the water into vapor (steam) - is the energy provided by the heater minus the energy lost due to radiative heat loss from the water:


{energy=((maxPwr*htrPwr)-radiation)}

We've see that the maximum power ratio is either 0.0 (fully off) or 1.0 (fully on).

The following is a critical strategy for making the dimensional analysis work across the entire system of "computation blocks":

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

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

The maxHeaterPower bound to maxPwr takes a value 400, and has been assigned a ValueType Power in joules per second (J/s), which is the same as watts (W).

Reality check: 400 W is only slightly larger than the consumption rating of a typical domestic "warm mist" humidifier appliance, and seems quite small if this is for a commercial humidifier servicing a large building. But it has a long time to act.

Remember:

Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is NOT assumed that the specification example is completely realistic (but an attempt is made to indeed interpret it as realistic using dimensional analysis and quantity magnitude checks).

Up next

BDD & IBD: Heating

Notes

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

[ASSERTION] Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "energy" 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.