I am trying to specify block connection through the modelica port interface and the port I am attempting to connect to within my library is named ports[1]. Upon exporting the SysMl code I am not able to generate the desired modelica text, resulting in the following code: connect(name.ports1,name2.port). Where name.ports1 is explicitly defined in the proxy port specification with the applied stereotype of ModelicaPort and ProxyPort with the tag name ports[1].

SYSPHS11-1 close

Our guess is the implementation the filer is using removes square brackets from port names because those are reserved notation in Modelica. The specification could require translation to remove platform special characters (or replace them with a non-special character) from SysML names, but these characters might differ between platforms and causes naming conflicts on translation.

Physical interaction is bidirectional, making it difficult to predict how a model will simulate, or to find the source of unintended simulation results (debug).

SYSPHS11-3 revision

See revised text.

The current examples are of physical interaction or signal flow separately (the humidifier example has signals carrying physical information, but doesn't use physical interaction).

SYSPHS11-2 revision

See revised text. Include file SysPhSAnnexA-CruiseControl.xmi among the non-normative artifacts (see zip file in resolution to SYSPHS11-6).

[Filed for Nerijus Jankevicius and Raphael Barbau] The table in 11.3.4 (Electrical components) and corresponding XMI in dtc/17-12-04/SysPhSLibrary.xmi are missing units.

SYSPHS11-11 revision

See revised text. Corresponding updates to SysPhSLibrary.xmi are in resolution to SYSPHS11-6.

In SysPhSLibrary.xmi, the elements corresponding to the *FlowElement interface blocks in Figure 31 (Elements for physical interaction) have Block applied instead of InterfaceBlock.

SYSPHS11-9 merge

In SysPhSLibrary.xmi, in stereotype applications to elements with names ending in "FlowElement", replace "Block" with "InterfaceBlock", and update the corresponding xmi:id (see SysPhSLibrary.xmi in resolution to SYSPHS11-6).

[Filed for Raphael Barbau] Currently SysML 1.4 / UML 2.5.

SYSPHS11-6 revision

Update the XMI artifacts below. See SYSPHS11-6-XMI.zip for machine-readable files (includes SysPhSAnnexA-CruiseControl.xmi for resolution to SYSPHS11-2).

• SysPhSProfile.xmi (normative)
• SysPhSLibrary.xmi (normative) (includes resolution of SYSPHS11-9 and changes in resolution of SYSPHS11-11)
• SysPhSAnnexA-ElectricCircuit.xmi (non-normative)
• SysPhSAnnexA-Humidifier.xmi (non-normative)
• SysPhSAnnexA-Hydraulics.xmi (non-normative)
• SysPhSAnnexA-SignalProcessor.xmi (non-normative)

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

SYSPISF_-90 machine files

See SysPhS-XMI.zip for machine-readable files:

• SysPhSProfile.xmi (normative)
• SysPhSLibrary.xmi (normative)
• SysPhSAnnexA-ElectricCircuit.xmi (non-normative)
• SysPhSAnnexA-Humidifier.xmi (non-normative)
• SysPhSAnnexA-Hydraulics.xmi (non-normative)
• SysPhSAnnexA-SignalProcessor.xmi (non-normative)

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

Merge SYSPISF_-89 into SYSPISF_-42

Merge SYSPISF_-89 into SYSPISF_-42

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

SYSPISF_-88 revision

_

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.

SYSPISF_-37 revision

See SYSPISF_-37-revised-text.docx for revised text.

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

SYSPISF_-42 revision

See SYSPISF_-42-revised-text.docx for revised text.

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

SYSPISF_-41 revision

See SYSPISF_-41-revised-text.docx for revised text.

Clause 10.9 is missing a summary section.

SYSPISF_-47 revision

See SYSPISF_-47-revised-text.docx for revised text.

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

SYSPISF_-40 revision

_

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

SYSPISF_-39 revision

See SYSPISF_-39-revised-text.docx for revised text.

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.

SYSPISF_-46 revision

_

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.

SYSPISF_-45 revision

See SYSPISF_-45-revised-text.docx for revised text.

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.

SYSPISF_-44 revision

See SYSPISF_-44-revised-text.docx for revised text.

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.

SYSPISF_-43 revision

See SYSPISF_-43-revised-text.docx for revised text.

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

SYSPISF_-48 revision

_

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

SYSPISF_-32 revision

See SYSPISF_-32-revised-text.docx for revised text.

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.

SYSPISF_-30 revision

See SYSPISF_-30-revised-text.docx for revised text.

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.

SYSPISF_-36 revision

See SYSPISF_-36-revised-text.docx for revised text.

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

SYSPISF_-34 revision

See SYSPISF_-34-revised-text.docx for revised text.

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.

SYSPISF_-33 revision

See SYSPISF_-33-revised-text.docx for revised text.

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.

SYSPISF_-38 revision

See SYSPISF_-38-revised-text.docx for revised text.

Simulation properties and blocks aren’t needed:

• Physical interaction could be modeled with fl owproperties typed by specialized conserved substance types that have potential and flow rate simulation variables. These could be in compartments labelled for physical interactions.
• Signal flow could be modeled with flow properties typed by Real, Integer, or Boolean, and that have SimVariable applied. These could be in compartments labelled for signal flows.

SysPISF_-5 revision

_

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.

SYSPISF_-31 revision

See SYSPISF_-31-revised-text.docx for revised text.

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.

SYSPISF_-29 revision

_

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

SYSPISF_-28 revision

_

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

SYSPISF_-35 revision

_

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

SYSPISF_-27 revision

_

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

SYSPISF_-26 revision

_

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

SYSPISF_-25 revision

_

In Figures 19 and 20, Fluid should be Volume.

Merge SYSPISF_-24 into SYSPISF_-5

SYSPISF_-24 into SYSPISF_-5

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

Merge SYSPISF_-23 into SYSPISF_-42

Merge SYSPISF_-23 into SYSPISF_-42.

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

Merge SYSPISF_-21 into SYSPISF_-5

Merge SYSPISF_-21 with SYSPISF_-5

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

Merge SYSPISF_-20 into SYSPISF_-5

Merge SYSPISF_-20 into SYSPISF_-5

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

Merge SYSPISF_-19 into SYSPISF_-5

Merge SYSPISF_-19 into SYSPISF_-5

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

Merge SYSPISF_-18 into SYSPISF_-5

Merge SYSPISF_-18 with SYSPISF_-5

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

Merge SYSPISF_-3 into SYSPISF_-5

Merge SYSPISF_-3 into SYSPISF_-5

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.

Merge SYSPISF_-22 into SYSPISF_-5

Merge SYSPISF_-22 into SYSPISF_-5

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.

Merge SYSPISF_-17 into SYSPISF_-5

Merge SYSPISF_-17 into SYSPISF_-5

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.

Merge SYSPISF_-16 into SYSPISF_-5

Merge SYSPISF_-16 with SYSPISF_-5

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

Merge SYSPISF_-15 into SYSPISF_-5

Merge SYSPISF_-15 into SYSPISF_-5

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

Merge SYSPISF_-14 into SYSPISF_-5

Merge SYSPISF_-14 into SYSPISF_-5

SimConstants should have the same type constraint as SimVariables.

Merge SYSPISF_-13 into SYSPISF_-5

Merge SYSPISF_-13 into SYSPISF_-5

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

Merge SYSPISF_-12 into SYSPISF_-5

Merge SYSPISF_-12 into SYSPISF_-5

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

Merge SYSPISF_-11 into SYSPISF_-5

Merge SYSPISF_-11 into SYSPISF_-5

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.

Merge SYSPISF_-6 into SYSPISF_-5

Merge SYSPISF_-6 into SYSPISF_-5

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

Merge SYSPISF_-1 into SYSPISF_-5

Merge SYSPISF_-1 into SYSPISF_-5

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.

Merge SYSPISF_-2 into SYSPISF_-5

Merge SYSPISF_-2 into SYSPISF_-5