1. OMG Mailing List
  2. SysML Extension for Physical Interaction and Signal Flow Simulation (SysPISF) 1.0 Finalization Task Force

Open Issues

  • Issues not resolved
  • Name: syspisf-ftf
  • Issues Count: 46

Issues Summary

Key Issue Reported Fixed Disposition Status
SYSPISF_-90 Machine files SysPISF 1.0b1 open
SYSPISF_-42 Property redefinition SysPISF 1.0b1 open
SYSPISF_-89 Platform limitation, nested initial values SysPISF 1.0b1 open
SYSPISF_-88 Restriction sections SysPISF 1.0b1 open
SYSPISF_-48 S-Function capitalization SysPISF 1.0b1 open
SYSPISF_-47 Default/initial summary SysPISF 1.0b1 open
SYSPISF_-46 SimulinkPort and ModelicaPort are optional SysPISF 1.0b1 open
SYSPISF_-44 Component library headers, behavior SysPISF 1.0b1 open
SYSPISF_-45 Component library names, arguments SysPISF 1.0b1 open
SYSPISF_-43 Platform library, constants, properties, multidimensional values SysPISF 1.0b1 open
SYSPISF_-41 Connector property in association block preprocessing SysPISF 1.0b1 open
SYSPISF_-40 Clause 6.2 not referring to Annex SysPISF 1.0b1 open
SYSPISF_-39 Modelica 3.4, eBNF SysPISF 1.0b1 open
SYSPISF_-37 Datatypes, units SysPISF 1.0b1 open
SYSPISF_-38 Assignments SysPISF 1.0b1 open
SYSPISF_-36 Platform block/property correspondences SysPISF 1.0b1 open
SYSPISF_-35 Simscape generalization example, nodes->components SysPISF 1.0b1 open
SYSPISF_-34 Simulink/Simscape block correspondences, clause order SysPISF 1.0b1 open
SYSPISF_-33 Package correspondences, clause order SysPISF 1.0b1 open
SYSPISF_-31 Connector clauses should give correspondences SysPISF 1.0b1 open
SYSPISF_-32 Simulink physical interaction SysPISF 1.0b1 open
SYSPISF_-30 Simscape left/right annotations, Simulink port arrays & blocks SysPISF 1.0b1 open
SYSPISF_-29 Connecting parts to themselves SysPISF 1.0b1 open
SYSPISF_-28 Expression language, function semantics SysPISF 1.0b1 open
SYSPISF_-27 changeCycle definition too restrictive SysPISF 1.0b1 open
SYSPISF_-26 Clause 7.2.2 should refer to simulation runs SysPISF 1.0b1 open
SYSPISF_-25 Scope: modeling vs performance SysPISF 1.0b1 open
SYSPISF_-24 Physical value types SysPISF 1.0b1 open
SYSPISF_-5 SimProperty/SimBlock not needed SysPISF 1.0b1 open
SYSPISF_-23 Multiple generalization SysPISF 1.0b1 open
SYSPISF_-21 Constraints in constraint blocks should be in compartments SysPISF 1.0b1 open
SYSPISF_-22 Preprocessing patterns SysPISF 1.0b1 open
SYSPISF_-20 State machine should use time events and library elements SysPISF 1.0b1 open
SYSPISF_-19 Physical constraint modeling text SysPISF 1.0b1 open
SYSPISF_-18 Stereotype constraint wording SysPISF 1.0b1 open
SYSPISF_-16 Missing constraints and multiplicities on SimConstant and SimVariable SysPISF 1.0b1 open
SYSPISF_-17 SimVariable semantics SysPISF 1.0b1 open
SYSPISF_-15 Specializations of primitive types SysPISF 1.0b1 open
SYSPISF_-14 Property types in constraints SysPISF 1.0b1 open
SYSPISF_-12 Stereotype labels SysPISF 1.0b1 open
SYSPISF_-13 SimConstant type constraints SysPISF 1.0b1 open
SYSPISF_-11 Use library in translations SysPISF 1.0b1 open
SYSPISF_-6 Physical interaction library SysPISF 1.0b1 open
SYSPISF_-3 Improve stereotype names SysPISF 1.0b1 open
SYSPISF_-2 More detail needed in Annex A SysPISF 1.0b1 open
SYSPISF_-1 Binding connector notation: Use "equal" instead of "equals" SysPISF 1.0b1 open

Issues Descriptions

Machine files

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The XMI files need to be updated (normative and nonnormative).

  • Reported: SysPISF 1.0b1 — Mon, 2 Oct 2017 21:37 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Property redefinition

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Correspondences are missing for property redefinition. These require constraints to ensure platform independence.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:07 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Platform limitation, nested initial values

  • Status: open  
  • Source: NIST ( Mehdi Dadfarnia)
  • Summary:

    Clause 10.9 should explain that Simulink does not support the equivalent of SysML nested initial values (ie, when S-functions are used).

  • Reported: SysPISF 1.0b1 — Mon, 2 Oct 2017 18:56 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Restriction sections

  • Status: open  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    The restriction sections in Clause 10 summary subclauses are redundant with the correspondences and can be removed.

  • Reported: SysPISF 1.0b1 — Mon, 2 Oct 2017 17:51 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

S-Function capitalization

  • Status: open  
  • Source: NIST ( Mehdi Dadfarnia)
  • Summary:

    Should be “S-function” (in free text, not in code boxes).

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:11 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Default/initial summary


SimulinkPort and ModelicaPort are optional

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Clause 11.3 should explain that SimulinkPort and ModelicaPort are only necessary when the name of the Simulink or Modelica port differs from the library port name. Otherwise, ports owned or inherited by SimulinkBlock or ModelicaBlock correspond to Simulink or Modelica ports of the same name, and SimulinkPort and ModelicaPort do not need to be applied.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:10 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Component library headers, behavior

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The table headers in Clause 11.3 are inconsistent, referring to either the type of element or a name, some capitalized and other not, and the platform columns are called out but not the component library columns. The behavior column is not explained well enough.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:08 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Component library names, arguments

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    In Clause 11.3, component block names should not have spaces, platform library paths are missing, and some of the names and arguments are incorrect.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:09 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Platform library, constants, properties, multidimensional values

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    In Clause 11.4, Modelica and Simulink parameters should be kinds of PhSConstants. The dimensions and value properties have the wrong types and multiplicities (and dimensions should be singular). The application of MultiDimensionalElement in 11.3 needs more explanation and multiplicities shown. Vector signal elements used in the component library are missing.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:07 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Connector property in association block preprocessing

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    The description of Figure 2 in Clause 9.2.2 should indicate it is using a SysML connector property.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:06 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Clause 6.2 not referring to Annex

  • Status: open  
  • Source: NIST ( Mehdi Dadfarnia)
  • Summary:

    In Clause 6.2, the last sentence should refer to Annex A, rather than 11.4.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:04 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Modelica 3.4, eBNF

  • Status: open  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Modelica 3.4 is available, as well as updated libraries. The spec should use them. Also update the eBNF reference.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:04 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Datatypes, units

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Clauses 10.10 and 10.6.11 should refer to valuetypes in SysML, rather than datatypes. Clause 10.10 should mention that the unit in the example is from the library in Figure 20 and should use the same notation in Figure 16. The type wording in the last row of the table in Clause 10.5.6 should be clarified. Correspondences should be given between standard and platform-specific unit symbols, and standard symbols used in Figure 20. Figure 20 should qualify Real, include time/seconds, and be in a clause at the same levels as component interaction/behavior.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:02 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Assignments

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Clause 6.1 distinguishes signal flow and physical interaction partly by whether assignments or equations are used, but signal flow mostly uses equations in the rest of the spec. The rest of spec refers to equations and assignments, but the expression language can also be used in ChangeExpressions.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:03 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Platform block/property correspondences

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    List the concrete Modelica and Simulink elements used under their abstractions (class and block respectively), with forward references as needed (Clause 10.2.3 in particular is too general). Simulink block correspondences in Clause 10.3.4 should be in 10.2.4. Clause 10.2.4 should refer to 10.3.4 for the details of models and libraries.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:01 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Simscape generalization example, nodes->components

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    The code example in Clauses 10.4.5 should use member components rather than nodes.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:01 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Simulink/Simscape block correspondences, clause order

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Clause 10.2.5 should be after 10.2.6 and refer to it for Simscape code.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 19:00 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Package correspondences, clause order

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Clause 10.3 should focus SysML package correspondences on platform elements, with files supporting the elements. Simscape has no language element corresponding to SysML packages, so the clause should explain in terms of Simscape files and compiled libraries. Code samples in Clauses 10.2 and 10.4 should reflect the SysML packages in 10.2.2 and 10.4.2, respectively (and the SysML figures should include blocks referenced in the package). Clause 10.3.4 code sample should separate model and library (saying more about their purpose and referring to Clause 10.2.4 for details about blocks). Clause 10.2 should be after 10.3.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:59 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Connector clauses should give correspondences

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Clauses 10.7.4 through 10.7.6 should give correspondences between SysML and simulation platforms, like the other clauses do. Some code is missing the container object shown in Figure 12 or uses a different name for it. Figure 12 uses Spring for two parts, but these parts are different in Clause 10.7.6.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:57 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Simulink physical interaction

  • Status: open  
  • Source: NIST ( Mehdi Dadfarnia)
  • Summary:

    Clause 10.6.9 is missing an example showing correspondences between SysML and Simulink.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:58 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Simscape left/right annotations, Simulink port arrays & blocks

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Left/right annotations should be used on all Simscape correspondences for nodes, inputs, and outputs (in case Simscape components are used by Simulink, which requires them). The Simscape code in Clause 10.8.6 should define inputs and outputs the same way as in Clause 10.6.6. Simulink’s use of arrays to specify ports should be explained, as well as block identifiers.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:56 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT
  • Attachments:

Connecting parts to themselves

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Clause 10.7 sometimes is worded as if simulation platforms and the correspondences with SysML do not support connectors between ports on the same part, but they do.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:55 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Expression language, function semantics

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    The last paragraph of Clause 8 states that the functions are available assuming translation, but function semantics doesn't depend on the translations.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:54 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

changeCycle definition too restrictive

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Clause 7.2.4 (SimVariable), Attributes, changeCycle, the text should include cases where the value does not change every interval.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:54 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Clause 7.2.2 should refer to simulation runs

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Clause 7.2.2 (SimConstant) should to simulation runs, rather than simulation in general. The second sentence isn’t grammatical.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:53 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Scope: modeling vs performance

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    In Clause 1 (Scope), the first bullet says the extension performs simulation, but the extension only models simulation.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:52 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Physical value types

  • Status: open  
  • Source: NIST ( Mehdi Dadfarnia)
  • Summary:

    In Figures 19 and 20, Fluid should be Volume.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:51 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

SimProperty/SimBlock not needed


Multiple generalization

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Multiple generalization is forbidden in 10.4.6, because it isn’t supported in Simscape, but this can be handled with additional correspondences.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:50 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Constraints in constraint blocks should be in compartments

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Figures 13 (Clause 10.8.3) and 14 (Clause 10.8.7) should display constraints in compartments.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:48 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Preprocessing patterns

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Clause 9 should include preprocessing for other common SysML modeling patterns, such as blocks with several simulation flow properties typing parts, blocks with non-simulation flow properties typing ports, and connectors between these.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:49 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

State machine should use time events and library elements

  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Figure 17 should use time events instead of change events for time-related events, and should use signal library elements.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:47 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Physical constraint modeling text

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    Clause 10.8.7 (SysML modeling, physical interaction) should include more information, as in Clause (10.8.3 SysML modeling, signal flow).

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:46 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Stereotype constraint wording

  • Status: open  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Some stereotype constraints that apply to the stereotyped element do not say that directly.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:45 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Missing constraints and multiplicities on SimConstant and SimVariable

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    For example: Conserved variables should be continuous. Continuous variables must be Real. Constants and variables should have redefinition constraints. Variables should have constraints for when they are on blocks typing connected parts or ports in internal block diagrams. Multiplicities on constants and variables are missing.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:36 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

SimVariable semantics

  • Status: open  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    The SimVariable description paragraph states that connected conserved sim variables have values of opposite sign. This is not true when more than two variables are involved.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:45 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Specializations of primitive types

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    The text should explicitly allow primitive type specializations to be used.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:34 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Property types in constraints

  • Status: open  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Clause 7.2.3 and 7.2.4 say ‘the type must be’, but don’t say the type of what.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:33 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Stereotype labels

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The stereotype clauses should specify the label used when displayed with elements it is applied to.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:27 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

SimConstant type constraints

  • Status: open  
  • Source: No Magic, Inc. ( Nerijus Jankevicius)
  • Summary:

    SimConstants should have the same type constraint as SimVariables.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:31 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Use library in translations

  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Clause 10 should use library elements where possible, for example, in 10.6.3 and 10.6.7.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:23 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Physical interaction library

  • Key: SYSPISF_-6
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The title of Clause 11.2 (Port types) should be changed to 'Component interaction'. Clarifications should be added that the components do not need to be used as port types. The conserved substances are quantity kinds, as in SysML, and should be referred to that way. They should have a common abstraction, specialized from SysML QuantityKind.

  • Reported: SysPISF 1.0b1 — Tue, 19 Sep 2017 18:19 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Improve stereotype names

  • Key: SYSPISF_-3
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    The stereotype defined in order to support simulation of physical and signal flows might also be used for specifying related system characteristics through a model, independently of any simulation intent.

    However, the "Sim" prefix used for each stereotype defined in this profile might discourage such an utilization and so it tends to restrict its domain of application. It's a shame.

    Consider using a more neutral prefix like "pisf" or avoiding using the "Sim" prefix for all of the stereotypes. Especially constants are of far broader interest than simulation only (and should event be introduced in SysML to me). The name "Constant" would be convenient. Also, I think that "SimVariable" could be renamed "FlowVariable".

  • Reported: SysPISF 1.0b1 — Thu, 27 Apr 2017 07:12 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

More detail needed in Annex A

  • Key: SYSPISF_-2
  • Status: open  
  • Source: NIST ( Mehdi Dadfarnia)
  • Summary:

    Filed for AB.

    Annex A needs to be more descriptive. It could use some more examples to explain the capabilities and scope of the extension and libraries.

  • Reported: SysPISF 1.0b1 — Mon, 8 Aug 2016 21:32 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT

Binding connector notation: Use "equal" instead of "equals"

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

    Figure 13, 14 shows binding connectors with keyword "equals". The keyword should be just "equal".

  • Reported: SysPISF 1.0b1 — Thu, 2 Feb 2017 16:34 GMT
  • Updated: Sat, 28 Oct 2017 00:22 GMT