SysML Extension for Physical Interaction and Signal Flow Simulation Avatar
  1. OMG Specification

SysML Extension for Physical Interaction and Signal Flow Simulation — Open Issues

  • Acronym: SysPhS
  • Issues Count: 33
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSPHS12-33 Suggest should explicitly support physical interactions with multiple conserved quantity flows (with examples) SysPhS 1.1 open
SYSPHS12-32 Suggest SysPhSLibrary should support Mass and FlowingMass as conserved quantities with MassFlowElement interface block and MassFlowRate value type. SysPhS 1.1 open
SYSPHS12-31 Suggest SysPhSLibrary should support Heat and FlowingHeat as conserved quantities with HeatFlowElement interface block and HeatFlowRate value type SysPhS 1.1 open
SYSPHS12-30 Suggest explicitly support the Modelica when/then statement SysPhS 1.1 open
SYSPHS12-29 Modelica: Suggest need option to NOT always set a 'start' value also as 'fixed' SysPhS 1.1 open
SYSPHS12-28 Suggest support Modelica's 'min' and 'max' on type declarations SysPhS 1.1 open
SYSPHS12-27 Suggest explicitly support Modelica's 'initial equation' SysPhS 1.1 open
SYSPHS12-26 The restriction of "vapor" to the range 0..1 in EvaporationCalculation2 seems completely arbitrary SysPhS 1.1 open
SYSPHS12-22 Meta-ticket: SysPhS-1.1 (dtc/20-08-02): Figure and diagramming/modelling issues SysPhS 1.1 open
SYSPHS12-23 The water temperature from TemperatureIncreaseConstraint and HeatingCalculationConstraint starts at 0 °C SysPhS 1.1 open
SYSPHS12-24 Use of == comparison with Real in not valid outside a function in Modelica SysPhS 1.1 open
SYSPHS12-25 The water temperature from TemperatureIncreaseConstraint and HeatingCalculationConstraint starts at 0 °C (should probably be the environment temperature 20 °C). SysPhS 1.1 open
SYSPHS12-19 Suggest BDDs should use explicit SysML Ports shown in compartments on Blocks instead of an apparently user-defined «port» keyword on Association ends SysPhS 1.1 open
SYSPHS12-18 Constraints on RelativeHumidityCalculationConstraint and HeatingCalculationConstraint not consistent between BDD Figure 79 and Parametrics Diagrams Figure 84 and Figure 88 SysPhS 1.1 open
SYSPHS12-16 The resistance:ViscousResistance in Figure 60 has to be treated as a PhSVariable not a PhSConstant or the systems of equations is ill formed SysPhS 1.1 open
SYSPHS12-3 The states StandBy and On in 'Figure 29: State machine in SysML' should probably use 'entry' not 'doActivity'. SysPhS 1.1 open
SYSPHS12-11 Overlapping Connectors in iBDs can give false impression of shared channel (and implied sum of flow) SysPhS 1.1 open
SYSPHS12-7 StateMachine in Figure 29 should be named ComputerSM (not Computer) for consistency with Modelica code SysPhS 1.1 open
SYSPHS12-21 In BDD Figure 101 in block HeatingCalculation1: there is no such value to redefine 'C1 : Time = 1.0{redefines C1,unit = second}', should be 'xIntg : Real' SysPhS 1.1 open
SYSPHS12-20 Diagram typo: RelativeHumidity should be named RelativeHumidity1 in 'Figure 98: Relative Humidiity Scenario Initial Values:' SysPhS 1.1 open
SYSPHS12-14 Meta-ticket: SysPhS-1.1 (dtc/20-08-02): Typos, editorial errors, cross reference errors SysPhS 1.1 open
SYSPHS12-17 Humidifier example: Direct Port conjugation not permitted since SysML-1.6, prefer ~InterfaceBlock type-based conjugation (example requires migration) SysPhS 1.1 open
SYSPHS12-15 The handling of initial values for usages of Tank within ConnectedTanks for Figure 59 breaks Single Source of Truth for value property 'gravity' SysPhS 1.1 open
SYSPHS12-13 Suggest kickstart SpringMassSys with a non-zero position (otherwise get flat line when run). SysPhS 1.1 open
SYSPHS12-2 Modelica code for Spring corresponding to 'Figure 22' has invalid 'in' and 'out' should probably be 'input' and 'output' SysPhS 1.1 open
SYSPHS12-5 Switch: Use of RealSignalInElement for u2 inconsistent with BooleanInput u2 of control port for Modelica.Blocks.Logical.Switch SysPhS 1.1 open
SYSPHS12-8 Typos: references to 'sigsp', 'rsig', and 'sig' should be 'rSig' SysPhS 1.1 open
SYSPHS12-12 Parameter v3 should not have a default in the Modelica code for Figure 21 SysPhS 1.1 open
SYSPHS12-10 Modelica code has 'forcediff=springcst*lengthchg;' should be 'forcethru=springcst*lengthchg;' SysPhS 1.1 open
SYSPHS12-9 Naming errors and typos in the Modelica code corresponding to Figure 25 SysPhS 1.1 open
SYSPHS12-6 Modelica Parameters for Subtraction row should indicate k2 required to achieve subtraction via Modelica.Blocks.Math.Add SysPhS 1.1 open
SYSPHS12-4 Incorrect references to 'RealInSignalElement' and 'RealOutSignalElement' (should be RealSignalInElement, RealSignalOutElement) etc. SysPhS 1.1 open
SYSPHS12-1 Typo in 10.3.3 SysPhS 1.1 open

Issues Descriptions

Suggest should explicitly support physical interactions with multiple conserved quantity flows (with examples)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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/

  • Reported: SysPhS 1.1 — Fri, 19 Mar 2021 01:26 GMT
  • Updated: Fri, 19 Mar 2021 14:54 GMT

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

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Fri, 19 Mar 2021 01:13 GMT
  • Updated: Fri, 19 Mar 2021 14:53 GMT

Suggest SysPhSLibrary should support Heat and FlowingHeat as conserved quantities with HeatFlowElement interface block and HeatFlowRate value type

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Fri, 19 Mar 2021 01:03 GMT
  • Updated: Fri, 19 Mar 2021 14:53 GMT

Suggest explicitly support the Modelica when/then statement


Modelica: Suggest need option to NOT always set a 'start' value also as 'fixed'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Wed, 17 Mar 2021 03:23 GMT
  • Updated: Wed, 17 Mar 2021 13:48 GMT

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

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

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

    Example:

    type Area=Real(unit="m2", min=0);
    
  • Reported: SysPhS 1.1 — Tue, 16 Mar 2021 23:57 GMT
  • Updated: Wed, 17 Mar 2021 13:48 GMT

Suggest explicitly support Modelica's 'initial equation'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Tue, 16 Mar 2021 23:53 GMT
  • Updated: Wed, 17 Mar 2021 13:48 GMT

The restriction of "vapor" to the range 0..1 in EvaporationCalculation2 seems completely arbitrary

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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)
    
  • Reported: SysPhS 1.1 — Sat, 27 Feb 2021 11:42 GMT
  • Updated: Wed, 3 Mar 2021 00:47 GMT

Meta-ticket: SysPhS-1.1 (dtc/20-08-02): Figure and diagramming/modelling issues

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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


  • Reported: SysPhS 1.1 — Tue, 23 Feb 2021 23:55 GMT
  • Updated: Wed, 3 Mar 2021 00:47 GMT

The water temperature from TemperatureIncreaseConstraint and HeatingCalculationConstraint starts at 0 °C

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Thu, 25 Feb 2021 22:56 GMT
  • Updated: Wed, 3 Mar 2021 00:46 GMT

Use of == comparison with Real in not valid outside a function in Modelica

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Sat, 27 Feb 2021 10:42 GMT
  • Updated: Wed, 3 Mar 2021 00:45 GMT

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

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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

  • Reported: SysPhS 1.1 — Sat, 27 Feb 2021 11:01 GMT
  • Updated: Wed, 3 Mar 2021 00:33 GMT

Suggest BDDs should use explicit SysML Ports shown in compartments on Blocks instead of an apparently user-defined «port» keyword on Association ends

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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

  • Reported: SysPhS 1.1 — Fri, 19 Feb 2021 04:16 GMT
  • Updated: Sat, 27 Feb 2021 10:56 GMT

Constraints on RelativeHumidityCalculationConstraint and HeatingCalculationConstraint not consistent between BDD Figure 79 and Parametrics Diagrams Figure 84 and Figure 88

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Fri, 19 Feb 2021 03:13 GMT
  • Updated: Sat, 27 Feb 2021 10:55 GMT

The resistance:ViscousResistance in Figure 60 has to be treated as a PhSVariable not a PhSConstant or the systems of equations is ill formed

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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))}
    
  • Reported: SysPhS 1.1 — Tue, 16 Feb 2021 08:58 GMT
  • Updated: Sat, 27 Feb 2021 10:53 GMT

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

  • Key: SYSPHS12-3
  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

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

  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 09:37 GMT
  • Updated: Sat, 27 Feb 2021 10:39 GMT

Overlapping Connectors in iBDs can give false impression of shared channel (and implied sum of flow)


StateMachine in Figure 29 should be named ComputerSM (not Computer) for consistency with Modelica code

  • Key: SYSPHS12-7
  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 10:32 GMT
  • Updated: Sat, 27 Feb 2021 10:38 GMT

In BDD Figure 101 in block HeatingCalculation1: there is no such value to redefine 'C1 : Time = 1.0{redefines C1,unit = second}', should be 'xIntg : Real'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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
    
  • Reported: SysPhS 1.1 — Fri, 19 Feb 2021 13:45 GMT
  • Updated: Sat, 27 Feb 2021 10:37 GMT

Diagram typo: RelativeHumidity should be named RelativeHumidity1 in 'Figure 98: Relative Humidiity Scenario Initial Values:'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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

  • Reported: SysPhS 1.1 — Fri, 19 Feb 2021 12:04 GMT
  • Updated: Sat, 27 Feb 2021 10:36 GMT

Meta-ticket: SysPhS-1.1 (dtc/20-08-02): Typos, editorial errors, cross reference errors

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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


  • Reported: SysPhS 1.1 — Fri, 12 Feb 2021 01:40 GMT
  • Updated: Tue, 23 Feb 2021 23:39 GMT

Humidifier example: Direct Port conjugation not permitted since SysML-1.6, prefer ~InterfaceBlock type-based conjugation (example requires migration)

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Wed, 17 Feb 2021 23:23 GMT
  • Updated: Thu, 18 Feb 2021 17:36 GMT

The handling of initial values for usages of Tank within ConnectedTanks for Figure 59 breaks Single Source of Truth for value property 'gravity'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Mon, 15 Feb 2021 12:00 GMT
  • Updated: Tue, 16 Feb 2021 10:20 GMT

Suggest kickstart SpringMassSys with a non-zero position (otherwise get flat line when run).

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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;
    
  • Reported: SysPhS 1.1 — Fri, 12 Feb 2021 01:03 GMT
  • Updated: Fri, 12 Feb 2021 18:01 GMT

Modelica code for Spring corresponding to 'Figure 22' has invalid 'in' and 'out' should probably be 'input' and 'output'

  • Key: SYSPHS12-2
  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 09:26 GMT
  • Updated: Fri, 12 Feb 2021 11:43 GMT

Switch: Use of RealSignalInElement for u2 inconsistent with BooleanInput u2 of control port for Modelica.Blocks.Logical.Switch

  • Key: SYSPHS12-5
  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

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

  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 10:12 GMT
  • Updated: Fri, 12 Feb 2021 00:20 GMT

Typos: references to 'sigsp', 'rsig', and 'sig' should be 'rSig'

  • Key: SYSPHS12-8
  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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==...
  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 10:26 GMT
  • Updated: Fri, 12 Feb 2021 00:01 GMT

Parameter v3 should not have a default in the Modelica code for Figure 21

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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

  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 11:27 GMT
  • Updated: Thu, 11 Feb 2021 14:25 GMT

Modelica code has 'forcediff=springcst*lengthchg;' should be 'forcethru=springcst*lengthchg;'

  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

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

    forcediff=springcst*lengthchg;
    

    Should be forcethru not forcediff:

     forcethru=springcst*lengthchg;
    
  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 11:04 GMT
  • Updated: Thu, 11 Feb 2021 14:25 GMT

Naming errors and typos in the Modelica code corresponding to Figure 25

  • Key: SYSPHS12-9
  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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;
    
  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 10:43 GMT
  • Updated: Thu, 11 Feb 2021 14:24 GMT

Modelica Parameters for Subtraction row should indicate k2 required to achieve subtraction via Modelica.Blocks.Math.Add

  • Key: SYSPHS12-6
  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 09:58 GMT
  • Updated: Thu, 11 Feb 2021 14:23 GMT

Incorrect references to 'RealInSignalElement' and 'RealOutSignalElement' (should be RealSignalInElement, RealSignalOutElement) etc.

  • Key: SYSPHS12-4
  • Status: open  
  • Source: Webel IT Australia ( Dr. Darren Kelly)
  • Summary:

    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, ...)

  • Reported: SysPhS 1.1 — Thu, 11 Feb 2021 09:49 GMT
  • Updated: Thu, 11 Feb 2021 14:23 GMT

Typo in 10.3.3

  • Key: SYSPHS12-1
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    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.

  • Reported: SysPhS 1.1 — Tue, 12 Jan 2021 06:28 GMT
  • Updated: Tue, 12 Jan 2021 06:28 GMT