Issues for Mailing list of the SysML-Modelica Transformation 1.1 (SyM) Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 17219: figure still uses <<conformsTo>> <<transformation>> and <<instanceOf>> applied to lines using the Dependency notation
Issue 17245: level of conformance for uni-directional transformation
Issue 17407: ModelicaShortExtends stereotype is needed
Issue 17408: Modelica expandable connectors and connect() statements that appear in a for or while loop
Issue 17409: Modelica components having as type a connector can have a declaration equation
Issue 17410: Modelica type can contain a Modelica function
Issue 17411: Modelica import statements
Issue 17537: INITIALEQUATIONS.contents : uEquationItem is *NOT* composite

Issue 17219: figure still uses <<conformsTo>> <<transformation>> and <<instanceOf>> applied to lines using the Dependency notation (sysml-modelica-rtf)

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

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

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

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

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. 

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.

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.

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.