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

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.