The namespace definition in the XMI and the URI attribute of the Profile is xmlns:SysML4Modelica=http://www.omg.org/spec/SysM/20120213. This uses SysM not the official directory (according to the other documents) which is the shorter SyM.

The spec name “SysM” was wrongly used in the XMI definition of the SysML4Modelica profile. It needs to be changed to the shorter "SyM" version.

The figure references UML4SysML which is no longer part of/used by the version of SysML (1.3) included in the normative references

The figure should reference UML package instead of the UML4SysML package.

The figure references UML4SysML which is no longer part of/used by the version of SysML (1.3) included in the normative references

See issue 17214 for disposition

In general the Part structure used is not appropriate for OMG specifications. It does not make sense to label Part I as non-normative. Especially as Part I includes Conformance and Normative References!

The part structure is kept since it is still considered helpful to structure the document. Part 1 needs to be labeled as normative.

the new figure still uses <<conformsTo>> <<transformation>> and <<instanceOf>> applied to lines using the Dependency notation. These have no defined meaning (either as keywords nor as stereotypes defined either in this specification, SysML or UML). Whatever <<instanceOf>> means it’s not the case that a transformationRecord is an instance of a transformation. If these stereotypes are retained there should be an explanation to say they are purely informal

An additional sentence needs to be added stating that the <<conformsTo>>, <<transformation>> and <<instanceOf>> stereotypes are purely informal

Section 2 includes in Level 0 Compliance “The SysML4Modelica profile must be compliant with OMG SysML v1.3.”. However a) this profile is part of this specification and b) SysML does not define compliance for Profiles. So it’s unclear what compliance would mean

In order to avoid any confusion, the sentence "The SysML4Modelica profile must be compliant with OMG SysML v1.3" should be remove.

In the SysML-Modelica Transformation Specification (http://www.omg.org/spec/SyM/1.0/Beta1/PDF/), the attribute fromLibrary for the stereotype «modelicaClassDefinition» is not sufficiently clearly defined (Section 8.2, page 10). The spec mentions that some details (e.g. "value properties and parts") can be omitted when using the fromLibrary tag, but the spec is not sufficiently precise as to which details exactly can/should be omitted and which should still be retained. Since this is a construct that will likely be used extensively, it should be defined more precisely.

The identified issue does not relate to the mapping of language constructs between SysML and Modelica but rather to a user- and tool-specific usability aspect of the transformation. The issue therefore does not identify a problem with the specification. Additionally, the “fromLibrary” attribute of the «modelicaClassDefinition» stereotype will be removed since it does not relate to the mapping of language constructs between SysML and Modelica.

A type containing a function is possible in Modelica. Example in the Modelica library: The record Modelica.Mechanics.MultiBody.Frames.Orientation contains the function named equalityConstraint. However, a DataType owning a FunctionBehavior is not possible in UML/SysML. So the containment relationship between a Modelica type and a Modelica function cannot be mapped into SysML4Modelica.

A component whose type is a connector can have a declaration equation. Example of a component definition in the Modelica library under Modelica.Blocks.Logical: "Modelica.Blocks.Interfaces.BooleanOutput condition=false;". A component whose type is a connector is mapped into a SysML port with a <<modelicaPort>> stereotype. The <<modelicaPort>> stereotype therefore needs an additional property to capture the declaration equation.

It is necessary to differentiate between short class definitions and class generalizations. A short class definition can have an input/output causality prefix whereas class generalizations cannot

I would have expected a level of conformance for uni-directional transformation – especially given the Overview which refers only to such.

the new figure still uses <<conformsTo>> <<transformation>> and <<instanceOf>> applied to lines using the Dependency notation. These have no defined meaning (either as keywords nor as stereotypes defined either in this specification, SysML or UML). Whatever <<instanceOf>> means it’s not the case that a transformationRecord is an instance of a transformation. If these stereotypes are retained there should be an explanation to say they are purely informal

Additional explanations are necessary on the mapping of expandable connectors and connect() statements that appear in a for or while loop

Ecore is used for the Modelica metamodel in Part III rather than EMOF (EMOF is also supported by the EMF technology). Oddly though I can see no depiction of the metamodel in either ecore or EMOF: I would for example expect to see some UML class diagrams. Instead there is what appears to be Modelica syntax.

The abstract syntax of Modelica, in other words its metamodel, needs to be represented in UML class diagrams. Figure 13 containing a representation of some Modelica metaclasses in an Ecore diagram will be replaced by UML class diagrams.

The SysML/Modelica spec includes a metamodel for the Modelica language:

http://www.omg.org/spec/SyM/20120301/openModelica.emof

The modelica language has a concept of initial equations & initial algorithms (see sec. 8.6).
The modelica language clearly states that initial equations/algorithms are added to the set of equations:

[A Modelica translator may first transform the continuous equations of a model, at least conceptually, to state

space form. This may require to differentiate equations for index reduction, i.e., additional equations and, in some

cases, additional unknown variables are introduced. This whole set of equations, together with the additional

constraints defined above, should lead to an algebraic system of equations where the number of equations and the

number of all variables (including der(..) and pre(..) variables) is equal. Often, this is a nonlinear system

of equations and therefore it may be necessary to provide appropriate guess values (i.e., start values and

fixed=false) in order to compute a solution numerically.

It may be difficult for a user to figure out how many initial equations have to be added, especially if the system

has a higher index. A tool may add or remove initial equations automatically such that the resulting system is

structurally nonsingular. In these cases diagnostics are appropriate since the result is not unique and may not be

what the user expects. A missing initial value of a discrete variable which does not influence the simulation

result, may be automatically set to the start value or its default without informing the user. For example, variables

8.7 assigned in a when-clause which are not accessed outside of the when-clause and where the pre() operator is

not explicitly used on these variables, do not have an effect on the simulation.]

The Modelica metamodel reflects this differently for initial algorithms than for initial equations.
Notice how INITIALALGORITHMS::contents is composite but INITIALEQUATIONS::contents is not.

<ownedType xmi:type="emof:Class" xmi:id="Absyn.ClassPart.INITIALEQUATIONS" name="INITIALEQUATIONS"
superClass="Absyn.ClassPart.uClassPart">
<ownedAttribute xmi:id="Absyn.ClassPart.INITIALEQUATIONS.contents" name="contents"
isOrdered="true" lower="0" upper="*" type="Absyn.EquationItem.uEquationItem"/>
</ownedType>
<ownedType xmi:type="emof:Class" xmi:id="Absyn.ClassPart.INITIALALGORITHMS" name="INITIALALGORITHMS"
superClass="Absyn.ClassPart.uClassPart">
<ownedAttribute xmi:id="Absyn.ClassPart.INITIALALGORITHMS.contents" name="contents"
isOrdered="true" lower="0" upper="*" type="Absyn.AlgorithmItem.uAlgorithmItem"
isComposite="true"/>
</ownedType>I believe that the metamodel should be changed to make INITIALEQUATIONS::contents composite and the QVTO transformations updated accordingly.

Modelica import statements should also be mapped into SyML4Modelica. It is then easier to implement the round-trip transformation between Modelica and SysML4Modelica and to verify the successful mapping.

Parsing of the profile XMI at http://www.omg.org/spec/SyM/20120320/SysML4Modelica-Profile.xmi results in a duplicate attribute error at line 14. xmi:type is defined twice in the packageImport statement that begins on line 13.

Source: Georgia Institute of Technology (Mr. Axel Reichwein, axel.reichwein(at)me.gatech.edu)
Summary: The QVT code shown in Annex C is incomplete. In addition, a figure showing an overview of the QVT implementation approach would be useful.

The QVT code in Annex C is outdated and has to be replaced by the latest
version. Since the current QVT code consists of approx. 5000 lines of code, it
would be too large to be placed in Annex C. Instead, Annex C should contain a
URL reference to a separate document containing all QVT transformations in a
zipped file. In addition, a figure showing an overview of the QVT implementation
approach should be placed in Annex C.

Not sure of the use of openmodelica.org.

Issues 16384 and 16385 address the correctness of using non-normative URIs to
identify the UML and Modelica metaclasses in the QVT transformation. The
implementation of the transformation in QVT includes references to the
metaclasses of both the UML and Modelica metamodels. These references are
found next to the “modeltype” keyword at the beginning of each QVT
transformation.
Since no normative Modelica metamodel exists, there are no normative URIs to
identify the Modelica metaclasses. The QVT code can thus not refer to Modelica
metaclasses through normative URIs and be considered normative. The use of
non-normative URIs to identify the UML and Modelica metaclasses in the QVT
transformation is therefore acceptable.
The QVT code does not need to be changed. However, the SysML-Modelica
Transformation specification should not state that Parts III, IV and V of the
SysML-Modelica Transformation specification are normative since they are all
based on a non-normative Modelica metamodel from openModelica.

Section 2 Conformance requires more detail for the practical definition of ‘full realization’ and ‘abstract syntax compliance’

Proposed change: leave out ‘full realization’ and ‘abstract syntax compliance’. In
addition, add a level 1 criteria referring to required level 0 compliance.

The UML Profile is represented in proprietary Eclipse format

The SysML4Modelica has been converted into OMG-grade XMI and has been added to the inventory of files which still includes the profile in Eclipse format.
Disposition:Resolved

As found by Lenny Delligatti of Lockheed Martin.

On page 5 of the spec., it shows that the SysML4Modelica profile references the SysML profile (Figure 2 in the screenshot below):

But I believe that’s an error. I believe that a «reference» dependency is only legal from a profile to a metamodel.

One profile can «import» another profile (and thus transitively reference a metamodel), but not «reference» another profile.

See issue 16545 for disposition

As found by Lenny Delligatti of Lockheed Martin.

On page 5 of the spec., it shows that the SysML4Modelica profile references the SysML profile (Figure 2 in the screenshot below):

But I believe that’s an error. I believe that a «reference» dependency is only legal from a profile to a metamodel.

One profile can «import» another profile (and thus transitively reference a metamodel), but not «reference» another profile.

A UML dependency can be between any two NamedElements. The dependency can also be tagged with any stereotype and be given any name. So the <<reference>> dependency is by itself legal. However, a keyword such as <<import>> can also be applied to a dependency.The <<import>> keyword seems more suitable to be applied on a dependency between profiles. So the <<reference>> dependencies to the UML4SysML metamodel (as shown in the SysML spec) in Figure 2 are kept and the <<reference>> dependency between the SysML4Modelica and SysML profiles in Figure 2 is replaced by an <<import>> dependency.

P6 uses ‘meta-case’ for transformation technology.

The capabilities of meta-CASE tools are not well-known. Therefore, the sentence
mentioning the implementation of the SysML-Modelica mapping by meta-CASE
tools is relaxed by referring to “tools” in general instead of “meta-CASE” tools.

6.1: this SysML issue does not belong here as such: if a change is needed it should be specified as a detailed edit to the SysML spec. Otherwise just raise the issue in the normal way.

Section 6.1 will be deleted.

Section 8: presumably these are production rules for Modelica syntax. Does this need to be duplicated in this spec?

No Data Available

Figure 2 uses stereotypes such as <<transformation>> that are not defined

The <<transformation>> stereotype is a self-defined stereotype referring to a
mapping definition.

3.1 should reference version 1.1 of QVT.
3.2: It’s not clear how the MDA Foundation Model ‘constitute provisions of this specification’.

Section 3.1 will reference version 1.1 of QVT and Section 3.2 will not refer to any
non-normative references including the MDA Foundation Model.

The QVT does not use the standard URI for the UML metamodel

No Data Available