SysML-Modelica Transformation Avatar
  1. OMG Specification

SysML-Modelica Transformation — Open Issues

  • Acronym: SyM
  • Issues Count: 9
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Modelica type can contain a Modelica function

  • Key: SYM11-6
  • Legacy Issue Number: 17410
  • Status: open  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    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.

  • Reported: SyM 1.0 — Tue, 5 Jun 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modelica components having as type a connector can have a declaration equation

  • Key: SYM11-5
  • Legacy Issue Number: 17409
  • Status: open  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    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.

  • Reported: SyM 1.0 — Tue, 5 Jun 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ModelicaShortExtends stereotype is needed

  • Key: SYM11-3
  • Legacy Issue Number: 17407
  • Status: open  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    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

  • Reported: SyM 1.0 — Tue, 5 Jun 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

level of conformance for uni-directional transformation

  • Key: SYM11-2
  • Legacy Issue Number: 17245
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: SyM 1.0b2 — Mon, 19 Mar 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

figure still uses <> <> and <> applied to lines using the Dependency notation

  • Key: SYM11-1
  • Legacy Issue Number: 17219
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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

  • Reported: SyM 1.0b2 — Fri, 9 Mar 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modelica expandable connectors and connect() statements that appear in a for or while loop

  • Key: SYM11-4
  • Legacy Issue Number: 17408
  • Status: open  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

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

  • Reported: SyM 1.0 — Tue, 5 Jun 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

INITIALEQUATIONS.contents : uEquationItem is *NOT* composite

  • Key: SYM11-8
  • Legacy Issue Number: 17537
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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.

  • Reported: SyM 1.0 — Thu, 2 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modelica import statements

  • Key: SYM11-7
  • Legacy Issue Number: 17411
  • Status: open  
  • Source: Koneksys ( Axel Reichwein)
  • Summary:

    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.

  • Reported: SyM 1.0 — Tue, 5 Jun 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI statement has duplicate attribute