Suggest should explicitly support physical interactions with multiple conserved quantity flows, and examples should be provided.

Example: Compressible fluid with mass and heat transfer:

connector ThermoFluid
    Modelica.SIunits.Pressure p;
    flow Modelica.SIunits.MassFlowRate m_flow;
    Modelica.SIunits.Temperature T;
    flow Modelica.SIunits.HeatFlowRate q;
end ThermoFluid;

See Modelica By Example: https://mbe.modelica.university/components/connectors/fluid_connectors/

Suggest the SysPhSLibrary should support Mass and FlowingMass as conserved quantities with a MassFlowElement interface block and a MassFlowRate value type.

Cases include modelling of compressible fluids.

Suggest the SysPhSLibrary should support Heat and FlowingHeat as conserved quantities with a HeatFlowElement interface block and a HeatFlowRate value type. (Entropy, FlowingEntropy, and EntropyFlowElement are already present but don't cover all thermodynamics cases.)

BTW: The suggested naming, which follows the SysPhS-1.1 naming pattern, is a bit strange in this case because 'heat' always implies flow/transfer.

Modelica 'when/then' statements are not explicitly listed under SysPhS-1.1 8 Language for Mathematical Expressions on p.9, which states that:

The SysPhS expression grammar includes a subset of Modelica’s grammar ...

The MagicDraw/Cameo tool v19SP3 does not cleanly export when/then statements used in Constraints.

The Modelica when/then statement is very widely used in practical problems, and is in most cases not replaceable by if/then/else statements. For example, many of the Modelica By Example studies involve when/then statements:

https://mbe.modelica.university/behavior/discrete/when/

StableBouncingBall under: https://mbe.modelica.university/behavior/discrete/bouncing/

SampleAndHold, IntervalMeasure, Counter, and CounterWithAlgorithm under: https://mbe.modelica.university/behavior/discrete/measuring/

HysteresisControlWithAlgorithms under: https://mbe.modelica.university/behavior/discrete/hysteresis/#hysteresis

See for example the Modelica University example:

model QuiescentModelUsingStart "Find steady state solutions to LotkaVolterra equations"
  parameter Real alpha=0.1 "Reproduction rate of prey";
  parameter Real beta=0.02 "Mortality rate of predator per prey";
  parameter Real gamma=0.4 "Mortality rate of predator";
  parameter Real delta=0.02 "Reproduction rate of predator per prey";
  Real x(start=10) "Prey population";
  Real y(start=10) "Predator population";
initial equation
  der(x) = 0;
  der(y) = 0;
equation
  der(x) = x*(alpha-beta*y);
  der(y) = y*(delta*x-gamma);
end QuiescentModelUsingStart;

Even without explicit support for 'initial equation' this can be reformulated for SysPhS with additional variables and equations. Export from MagicDraw gives:

model QuiescentModelUsingStart
  parameter Real alpha(start=0.1,fixed=true);
  parameter Real beta(start=0.02,fixed=true);
  parameter Real gamma(start=0.4,fixed=true);
  parameter Real delta(start=0.02,fixed=true);
  Real x(start=10.0,fixed=true);
  Real y(start=10.0,fixed=true);
  Real dx(start=0.0,fixed=true);
  Real dy(start=0.0,fixed=true);
equation
  der(x)=x*(alpha-beta*y);
  der(y)=y*(delta*x-gamma);
  dx=der(x);
  dy=der(y);
end QuiescentModelUsingStart;

The Wolfram SystemModeler tool declares that invalid because of these (which contradict the other initial conditions):

  Real x(start=10.0,fixed=true);
  Real y(start=10.0,fixed=true);

If you change the code (by hand) to the following it runs:

  Real x(start=10.0);
  Real y(start=10.0);

But SysPhS-1.1 seems to assume these should always be generated with fixed=true. The only way to get the example to work from SysPhS is to hack the start values (know the steady state value solutions in advance) thus:

  Real x(start=20.0,fixed=true);
  Real y(start=5.0,fixed=true);

Then it validates and runs.

Suggest support Modelica's 'min' and 'max' on type declarations.

Example:

type Area=Real(unit="m2", min=0);

Suggest explicitly support Modelica's 'initial equation'.

One can sometimes work around the lack of 'initial equation' by introducing additional ConstraintBlock equations for additional parameters and additional bound variables with 'start' values, but that does not always work.

The restriction of "vapor" to the range 0..1 in EvaporationCalculation2 seems completely arbitrary, it is not a ratio. Dimensional analysis and the names of conversion parameters and related value properties indicate it's a volumetric flow rate:

p.92 Figure 79: Humidifier constraint blocks

p97 Figure 91: Parametric diagram applying the second evaporation calculation constraint

{vapOut=g*(((max(min(vapor,1),0))*max((temp-boil),0)/(temp-boil))+np(max((boil-temp),0)/(boil-temp)))}

This part is not necessary:

max(min(vapor,1),0)

This meta-ticket collects issues concerning diagrams. Minor diagramming issues and minor inconsistencies can be reported one per comment here. More significant issues in diagrams requiring discussion and ballot voting can be raised as individual issues linked to this meta-ticket.

For typos and editor issues in the text of the specification please visit instead: https://issues.omg.org/browse/SYSPHS12-14

The water temperature from TemperatureIncreaseConstraint and HeatingCalculationConstraint starts at 0 °C (it should probably start at the environment temperature 20 °C).

{increase=energy/(specificHeat*waterVolume)}

{tOut=max(min(100,x),0)}
{der(x)=tInc/c1}

HeatingCalculationConstraint needs an additional parameter as integration constant with a realistic initial value set via an additional value property binding in HeatingCalculation.

On p.98 in Figure 93: Heater Control State Machine Diagram and Figure 94: Humidifier Control State Machine Diagram.

The StateMachines HeaterControlSM and ControlStateMachine have comparisons using == with Real, which is invalid in Modelica outside a function.

Examples:

when (modeIn.rSig==0)

when (waterVolumeIn.rSig==0)

At least in Wolfram SystemModeler this is reported as invalid and will not execute.

The water temperature from TemperatureIncreaseConstraint and HeatingCalculationConstraint starts by Modelica default at 0 °C (should probably be the environment temperature 20 °C). From HeatingCalculationConstraint:

{tOut=max(min(100,x),0)}
{der(x)=tInc/c1}

It needs a realistic startup parameter and value.

See Figure 79: Humidifier constraint blocks and Figure 88: Parametric diagram applying the heating calculation constraint

Throughout the spec many (not all) BDDs show Association ends with an apparently user-defined «port» keyword defined. It is not made clear in some cases whether this is applied to a Port OR a Property (to indicate it's being used as a "port"). This reporter (who is otherwise quite a fan of the associative graphical approach for some modelling tasks and audiences) recommends that this diagramming approach be removed and replaced with simple listing of Ports in compartments of Blocks, which makes it absolutely clear that Ports are used.

There are many examples of use of this user-defined «port» keyword in Annex A such as:

• BDD: Figure 39: Electrical blocks, ports & component properties

• BDD: Figure 49: Total system (source to sink) blocks, ports, & component properties

The corresponding IBDs don't show (or need) the «port» keyword anyway:

• IBD: Figure 47: Internal structure of test bed from signal source to sink

There seem to be some other inconsistent cases. For example, on p. 38 in PD Figure 25: Constraint block for signal flow in SysML it appears to show the u.sig and y.sig (should BTW be u.rSig and y.Sig) as Property symbols with SysML property-path dot notation, rather than as Port symbols on the block boundary. There is no exact corresponding BDD, but it's inconsistent compared with Figure 23: Ports for physical interaction in SysML on p.31, which just using a Ports compartment on a Block.

This issue has also been identified in the SysML-1.6 spec under SYSML17-351 If there is no «port» keyword in UML-2.5.1 or SysML-1.6 it should be removed from Figure 9-8

The BDD on p.92 Figure 79: Humidifier constraint blocks has for RelativeHumidityCalculationConstraint:

{der(x)=((press/satVap)-change)/c2}

The PD on p.94 Figure 84: Parametric diagram applying the relative humidity calculation constraint has for rHCC : RelativeHumidityCalculationConstraint:

{der(x)=(press/satVap)-change}

Note there is no c2.

The BDD on p.92 Figure 79: Humidifier constraint blocks has for HeatingCalculationConstraint:

{der(x)=tInc/c1}

The PD on p.96 Figure 88: Parametric diagram applying the heating calculation constraint has for hCC : HeatingCalculationConstraint:

{der(x)=tInc}

Note there is no c1.

In Figure 60: Hydraulics blocks, ports, & component properties

The resistance:ViscousResistance has to be treated as a PhSVariable not a PhSConstant or the system of equations for ConnectedTanks is ill formed. Validation of the export in one Modelica tool gives:

    The model has 6 variables and 7 equations.

Even though resistance:ViscousResistance is effectively a constant (as it is always computed from values that don't change with time) it is in fact handled like a variable via a Constraint:

{resistance=(8*viscosity*length)/(3.1416*(radius^4))}

The states StandBy and On in 'Figure 29: State machine in SysML' should probably use 'entry' not 'doActivity'.

Tool test: The MagicDraw/Cameo tool does not see a 'doActivity' on a State (does not write it to a Modelica algorithm), one must use an 'entry'!

Advise against diagramming style used in examples Figure 68 and Figure 69, which show overlapping Connectors in Internal Block Diagrams

In Figure 68: Internal structure of the humidifier, from a Port named vapourOut.

In Figure 69: Internal structure of the vapor generation plant, from a Port named temperatureOut.

This can give a false impression of shared channel (and implied sum of flow).

In the case of electrical current, the lines drawn that way indeed by convention imply currents meeting a node, whereas in the SysML diagram there is no node at all.

The StateMachine shown in Figure 29 on p.47 should be named ComputerSM (not Computer) for consistency with the Modelica code given on p.48.

Annex A.5: p.101: Figure 101: Heating Scenario Initial Values: redefined value in block HeatingCalculation1 is:

C1 : Time = 1.0{redefines C1,unit = second}

There is no such value in the extended block HeatingCalculation. Compare with p.90 BDD Figure 77: Heating blocks, ports, & component properties, has:

xIntg : Real

This is consistent with p.96 PD: Figure 88: Parametric diagram applying the heating calculation constraint, has Property symbol for:

xIntg : Real

On p.100: The BDD for RelativeHumidityScenario1 Figure 98: Relative Humidiity Scenario Initial Values the block RelativeHumidity should be named RelativeHumidity1 for consistency with Figure 96: Humidifier System Scenario Initial Values and Figure 97: Humidified Room Scenario Initial Values on p.99

This meta-ticket collects minor editorial errors in SysPhS-1.1 (dtc/20-08-02). The initial submission contains multiple reports separated by lines, and may be extended by per-comment reports as future typos and minor editorial errors are identified. The page numbers refer to the display page numbers at the bottom of the page (not the document page number by physical page count).

p.3 Unnecessary 'and' in:

The differences between physical interaction and signal flow and lie mainly in how components interact

p.22 under 10.3.3 Modelica modeling

Some redundant, almost identical text is given under the Modelica code box

It has a model A corresponding to the SysML block A, with a component b1 typed by Modelica model B,
corresponding to the SysML property b1 typed by block B.

p.37: The section marker for '10.9 Blocks with constraints' appears as 'Blocks with constraints' (no number) in the PDF (at least in Adobe Reader on Mac).

p.38: Under 10.9.4 Modelica modeling, signal flow

Probably wrong reference to Figure 13

The following Modelica code corresponds to Figure 25. It has three equations from the constraint block. SysML parameter names are replaced in the Modelica equations according to the bindings in Figure 13

p.44: Under 10.10.3 Modelica modeling

Reference in 'The following Modelica code corresponds to Figure 15' should probably be 'to Figure 27'.

p.45: Under 10.11.2 SysML modeling

Reference to 'the units library in Figure 20, Subclause 11.2.2' is wrong.

p.61: Trivial: Spacing around colon in table for electrical components is not consistent:

ron : Resistance
goff:Conductance
vforward:Voltage

p.63: reference to Figure 30 should probably be Figure 31 in:

Figure 32 and Figure 33 give additional signal elements and value types with units for electrical modeling
(see Figure 30 and Figure 34).

p.87 Strange floating S at top border of IBD Figure 68: Internal structure of the humidifier. Can be seen on Adobe Reader on Mac

p.88 describes use of UML-style direct conjugation of Ports, along with a contrived additional ~ indicator alongside Port names in BDDs Figure 72 through Figure 78:

Figure 72 through Figure 78 show block definitions for component used in the internal block diagrams shown in Figure 65 through Figure 71, respectively (one each for the total humidifier system, humidified room, relative humidity, humidifier, vapor generation plant, heating, and environment components). All ports are typed by RealSignalInElement from the signal flow library (see Subclause 11.2.1). A tilde (~) next to a port name indicates that it receives signals (conjugated port type), otherwise the port sends signals (the tilde normally appears before the type name, after a colon, but port types are omitted from the figures for brevity, because they are all the same

Since SysML-1.6, direct UML-style conjugation of Ports is no longer permitted, the examples needs to be migrated to use ~InterfaceBlock type-based conjugation (the reported has already performed migration in a highly annotated project, but it includes significant - and more consistent - renaming throughout so might not be directly suitable as a replacement).

Even once a migration to use ~InterfaceBlock is performed, a question remains about the benefit of the contrived additional ~ tilde conjugation indicator near Port names in BDDs. If the Ports in the BDDs are simply listed in compartments, instead of being shown as Association end Properties, the conjugated ~Type can be shown. Note also that the additional ~ is not shown in the corresponding IBDs anyway.

Even though not yet directly supported in the tool, creation of a customised ~InterfaceBlock Stereotype in the MagicDraw/Cameo tools since v19SP3 is straightforward.

On p.81 the IBD Figure 59: Internal structure of hydraulics system shows identical initial values 9.8 for the value property gravity for two distinct usages of Tank in the context of ConnectedTanks. Similarly, identical values 10.0 for fluidDensity are shown.

Unless the Tanks are subject to separate gravitational forces (unlikely) this appears to break Single Source of Truth. It is in any case not an ideal example (given that some users might blindly copy the approach on real-world engineering projects).

The specification doesn't in fact explicitly state that in the particular example all initial values are handled by Slots on InstanceSpecifications as initial value carries, but does seem to imply it here (and elsewhere):

SysML initial values specify property values for components used in internal block diagrams. Figure 59
shows initial values for fluid density, gravity, tank surface area, pipe radius, pipe length, and dynamic
viscosity of the fluid (properties defined in Subannex A.4.4).

In any case, at least gravity and probably also fluidDensity, are better handled as simple Property::defaultValue assignments for their corresponding value properties in block Tank. At least in the MagicDraw/Cameo tool these then appear to "shine through" (Translucency) in the initialValues compartment on IBDs, alongside any context-specific values for different value properties.

Indeed leaving only fluidLevel (typically initially different between Tanks) and tankSurfaceArea (possibly different between Tanks) handled via Slots on InstanceSpecifications, while handling gravity and fluidDensity through Property::defaultValue assignments, would offer a good contrast between the approaches. This might require an additional diagram.

p.38/39 show Modelica code corresponding to Figure 25: Constraint block for signal flow in SysML (and other model aspects not explicitly shown).

The Modelica code has some initial values for some parameters, but not for variables position or velocity, so if you execute it you just get a flat line. The reporter suggests including a default value such as position=5.0 in the SysML model to kickstart it.

The improved Modelica code, including some fixes identified under (https://issues.omg.org/browse/SYSPHS12-9) and with consistent name SpringMassSys might look like:

model SpringMassSys
  input Real u;
  output Real y;
  Real position(start=5.0,fixed=true);
  Real velocity;
  parameter Real springcst(start=1.0,fixed=true);
  parameter Real mass(start=10.0,fixed=true);
equation
  der(velocity)=(u-springcst*position)/mass;
  der(position)=velocity;
  y=position;
end SpringMassSys;

Or if the suggestion under (https://issues.omg.org/browse/SYSPHS12-2) to use connectable u and y is adopted:

model SpringMassSys
  Modelica.Blocks.Interfaces.RealInput u;
  Modelica.Blocks.Interfaces.RealOutput y;
  Real position(start=5.0,fixed=true);
  Real velocity;
  parameter Real springcst(start=1.0,fixed=true);
  parameter Real mass(start=10.0,fixed=true);
equation
  der(velocity)=(u-springcst*position)/mass;
  der(position)=velocity;
  y=position;
end SpringMassSys;

Reporter: Darren Kelly, Webel IT Australia

On p.30 the example Modelica code for Spring corresponding to 'Figure 22: Ports for signal flow in SysML' is invalid, the use of the invalid Modelica keywords in and out is probably a typo:

model Spring
  in Real u;
  out Real y;
end Spring;

Probably the following with input and output is intended :

model Spring
  input Real u;
  output Real y;
end Spring;

Note further, however, that the direct use of input Real and output Real does not correspond well with the SysML concept of Port, as they are not connectable. Compare with the connectable forms:

model Spring
  Modelica.Blocks.Interfaces.RealInput u;
  Modelica.Blocks.Interfaces.RealOutput y;
end Spring;

Where Modelica.Blocks.Interfaces.RealInput is just:

connector RealInput = input Real;

And Modelica.Blocks.Interfaces.RealOutput is just:

connector RealOutput = output Real;

One can get away with using the non-connectable forms when the system is self-contained, such as the SpringMassSys example on p.38, however I suggest this does not correspond well with SysML user expectations and the opportunity could be taken to use the connectable forms throughout most Modelica examples in the spec.

The table for 11.3.2.7 Routing components implies a RealSignalInElement for u2 for Switch.

A Modelica.Blocks.Logical.Switch has a control port u2 of type BooleanInput.

In at least one Modelica tool it is not permitted to connect from a RealOutput to a BooleanInput.

This also renders the use of 'Criteria = u2~=0' for the Simulink Switch inconsistent w.r.t. the Modelica Switch, because there is no way to check whether the control input is nonzero.

Also, the Modelica and Simulink equivalents for Switch are not made explicit (they appear to be missing from the table row).

On p.47 in text: References to 'u.sigsp' and 'u.sigsp' should be 'u.rSig' and 'y.rSig'.

In Figure 29: State machine in SysML:

• References to y.rsig (in doActivity in Actions) should be y.rSig.

• References to u.sig==... on Transitions should be u.rSig==...

The Modelica code on p.28 has:

parameter Real v3 = “...”;

No default is defined in Figure 21: PhSVariables and PhSConstant in SysML and "..." is not a good value indicator for a Real anyway.

hope not too trivial to report

Modelica code for Spring at top section of p.42 has:

forcediff=springcst*lengthchg;

Should be forcethru not forcediff:

 forcethru=springcst*lengthchg;

In the exported Modelica code on p.38 the model should be SpringMassSys (not Spring) for consistency with the text:

The block SpringMassSys has a SysML constraint property smsc typed by SMSConstraint.

This then also matches the name of the Parametric diagram SpringMassSys.

The Modelica code portion on p.39 has the incorrect keyword 'equations' not 'equation'.

The following equation incorrectly uses the variable 'm' instead of 'mass':

der(velocity)=(u-springcst*position)/m;

Should be:

der(velocity)=(u-springcst*position)/mass;

In Table 11.3.2.5 Mathematical components in the Modelica Parameters column for the Subtraction row it should indicate k2 required to achieve subtraction via Modelica.Blocks.Math.Add (assuming that k1 for Modelica takes its default +1).

If k2 is intended to be negative it would help to indicate this constraint.

Typos.

In text on p.30 and in Figure 22: Incorrect references to 'RealInSignalElement' and 'RealOutSignalElement' (should be 'RealSignalInElement', 'RealSignalOutElement')

In text on p.47: Incorrect references to 'RealInSignalElement' and 'RealOutSignalElement'

On p.53: Figure 30: Incorrect references to RealInSignalElement, RealOutSignalElement, IntegerInSignalElement, IntegerOutSignalElement, BooleanInSignalElement, BooleanOutSignalElement (should be RealSignalInElement, RealSignalOutElement, ...)

Typo: '10.3.3 Modelica modeling' some almost identical repeated text

The following Modelica example corresponds to the SysML block A in Figure 18. It has a Modelica model A corresponding to the SysML block A, with a component b1 typed by Modelica model B, corresponding to the
SysML property b1 typed by block B.

...

It has a model A corresponding to the SysML block A, with a component b1 typed by Modelica model B, corresponding to the SysML property b1 typed by block B.

Note: Spotted by Darren Kelly.