IBD: Context for SimpleDomesticInverterAirCon - detailed

This Internal Block Diagram (IBD) shows a usage of the «system» block SimpleDomesticInverterAirCon - with internal details showing - within the «system context» block SimpleDomesticInverterAirConContext, along with usages of a block External representing the outdoor environment and a usage of an air-conditioned IndoorSpace:

Click on the image to view it full size

A word on some naming and display options

Both the names and the Types of Ports external to :SimpleDomesticInverterAirCon have been shown here. By contrast, to reduce clutter, the Types of most Ports internal to :SimpleDomesticInverterAirCon are not displayed explicitly in this diagram. To some extent this modelling option has been used:

Webel Best Practice: UML/SysML: In Internal Block Diagrams: If you have a Port with a name that indicates a unique role AND and if there is an ItemFlow on a Connector that implies or suggests the Type of the Port, consider hiding the Type on the Port symbol.

Note that sometimes it's sufficient to instead only show the Port type. The gist is that it's seldom necessary to show both the name and the Type of every Port and it can make Internal Block Diagrams harder to read.

Note, by contrast, that every usage of a Block is anonymous (which is sufficient for this trail because the usages are not being exported to, for example, Modelica or Simulink):

Webel Best Practice: SysML: Webel: "Trust the Type!" - Often the name of the Type of an anonymous Property or instance-level element is completely sufficient to indicate its role - unless multiple Properties of the same Type have different roles within the same owner context!

The temperature control loop and the refrigerant cycle as ItemFlows

There's a lot to discuss here, and plenty to learn about SysML modelling options, so settle in as we work our way through the entire flow cycle.

Some of the ItemFlows have an itemProperty applied. This is a nice way of demonstrating the transformations of stuff that is flowing, such as the refrigerant.

On a SysML modelling matter, it would be nice to be able to show more information about each itemProperty on an ItemFlow on a Connector:

WISHLIST: Webel has suggested that future SysML should support the display of Classifier-level :features in compartments on a rectangular itemProperty symbol on an ItemFlow on a Connector in an IBD.

In the meantime, one can always just (slightly redundantly and verbosely) show the Property symbol for each itemProperty on the IBD and expose their :values compartments. (SysMLv2 is going to have some more powerful ways of carrying and displaying such information.)

We'll start our journey with the sensed temperature and our simple control loop. Recall first this recommendation:

Webel Best Practice: Progressively "exporting" internal Ports of usages of Blocks to the boundary of their using Block may seem like a bit of extra work, but it means you can progressively develop with clean black box views without the Connectors crossing Block boundaries.

So there's an explicit input Port iTemperatureSensor delegating to a similar Port on :InverterSubsystem, which accepts the sensor input as the temperatureGot value and uses it to determine the frequencyAim of the power driving the :Compressor, on the basis of the difference between the temperatureGot and the temperatureAim. This ultimately changes the rpm of the :Compressor.

The (hopefully fully) evaporated:RefrigerantVapour at low pressure is transformed in the :Compressor to super hot compresssed:RefrigerantVapour, which enters the :Condensor.

An :ExternalBlower draws in cooler external air which is used to help cool and condense the refrigerant. The hotExpelledAir:Air is ejected to the :External environment.

The condensed:RefrigerantLiquid then passes to the :ThermalExpansionValue, which is in this model an old mechanical style TXV/TEV with a :PoppetValue, which has a diaphragm that is equalised with the pressure of a :SensingBulb (typically placed near the top of the :Evaporator and connected via a metal capillary to the head of the thermal expansion value so its charge pushes on the diaphragm). The temperature of the :SensingBulb equalises with the temperature at the top of the :Evaporator to measure any "superheat". This is indicated by a custom stereotype keyword «equilibrium».

If you want to learn how a basic mechanical thermal expansion valve works visit these links (after completing this SysML trail of course):

Visit also (later): Links: How Thermal Expansion Valves works

You'll recall from a previous slide that the Port types for the pressure equalisation and temperature equalisation were modelled SysPhS-style, but no actual calculations are done in this trail, it's just assumed that «equilibrium» is reached quickly, as indicated by a custom stereotype keyword.

The evaporation of the expanded:Refrigerant (a tuned mixture of liquid and vapour) results in cooling of the warmReturn:Air drawn using a :ChillerFan, and coolSupply:Air is injected to the :IndoorSpace, cooling the room as required to hopefully approach the temperatureAim.

So that's a physical representation of the flows and transformations; let's now see how in SysML we can also represent the refrigerant part of that cycle as a StateMachine driven by Activities.

Up next

StateMachine for Refrigerant states

Notes

[CAVEAT, MODELLING]{INFORMATIVE} Dependency/Usage relationships in some referenced UML/SysML diagrams on this site are for educational illustration only, they are NOT part of the actual model.

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

[MODELLING, STYLE, TIP] Progressively "exporting" internal Ports of usages of Blocks to the boundary of their using Block may seem like a bit of extra work, but it means you can progressively develop with clean black box views without the Connectors crossing Block boundaries.

[MODELLING, STYLE, TIP, TOOL]{INFORMATIVE} MagicDraw SysML/Cameo has a nice feature 'Tools > Delegate Port(s)' accessible from the context menu for splitting Connectors that cross block boundaries into multiple Connectors with "exporting" Ports.

[ASSERTION, TOOL] SysML: The «system», «subsystem», «external», «domain» and «system context» keywords are for "user defined" block Stereotypes (they are not part of core SysML); they are supported in MagicDraw/Cameo as Non-Normative Extensions.

[TIP, WORKAROUND]{INFORMATIVE} [HISTORICAL] HOWTO easily "hack" the SysML-1.6 ~InterfaceBlock conjugation and «~interfaceBlock» keywords in MagicDraw/Cameo. [NOW SUPPORTED 2024x Golden]

[POLICY] Since SysML-1.6 use of direct UML conjugation of Ports is NOT supported; If you are using InterfaceBlocks use instead a conjugated ~InterfaceBlock type!