1. SysML Modelica Integration Working Group Meeting 3/4/09
Chris Paredis
Make note of web-sites that Sandy included.
Talk to Peter Fritzson – align both short-term and long-term perspectives.
Issue: causality into parametrics – propose a solution
(for this RTF: officially on May 25; work something out and discuss with Russell)
Create a plan for a face-to-face meeting: decide whether we need it and then decide
We are not trying to align terminology –
Read-only as property to reflect “constant”

2. Notes from previous calls
Organizational:
We need to set up a private wiki, but outside the OMG members-only wiki (AI: Roger, Chris)
Once we have some initial result, we should post them on the following websites: sysml-modelica.[org;net;com] modelica-sysml.[org;net;com]
Add Objective to focus/scope statement: leverage the strengths of both languages and integrating them to create a more expressive and formal MBSE language.
Make sure that both short- and long-term objectives of all stakeholders are in line.
Semantic comparison:
Flows in Modelica refer to anything that satisfies Kirchhoff’s laws (not just energy)
One may be able to map parameters to read-only quantities in SysML (clarification by Sandy)
We should standardize the sign conventions for flow variables in SysML — rather than leave it completely free to library developers
Conclusions:
We do not need to consider ACT diagrams any longer
Mapping to PAR and IBD needs further discussion

3. Case 2 (updated!): Modelica  PAR
Equivalent Modelica Model
Notes:
Not all constraint parameters are shown
According to the spec, «constraint» should not appear on the constrain blocks in a PAR diagram, but if I turn it off in MagicDraw, then «ModelicaModel» disappears also
«constraint» should not appear – could be a MagicDraw problem
Binding connectors have very different semantics
Check kirchhoff’s Law

4. Structure BDD and IBD
Example has been updated to make it more easily comparable to Sandy’s example
Consider a simplified model for a car body connected to a car suspension

5. Analysis Context
To describe the dynamic behavior, the structural components are related to corresponding dynamic model components in a «ModelicaModel»
A «Describe» stereotype (based on Dependency) is used to establish this relationship
NOTE: It was pointed out last time that it would be better for the Modelica models to be called “SpringEquations” or so rather than just “Spring” to avoid the potential confusion with a structural component for a spring. However, if we want to build on the Modelica Standard Library, then we almost have to stick to the model names used in that library. As an alternative, I could set the presentation options in MagicDraw such that the qualified type name shows up (e.g., Modelica::Mechanics::Translational::Components::Spring); this would make it clear that it is a Modelica model (rather than a structural model), but would make the name so long that the diagram would quickly become unreadable.

6. Parametric Diagram (see next slide)
The «ModelicaModel» components are related to each other by connecting the «ModelicaConnectors»
The «ModelicaParameters» are bound to the properties of the structural components
Other «ModelicaParameters» may be bound to properties defined in this particular analysis context

7. We could

8. Questions for Discussion
One could argue that we are using constraint parameters to “define” variables rather than just “constrain” them. For instance, mass1model::L has a default value of 0 in Modelica and could thus be left unbound in the diagram. Is this a good idea? What are the alternatives?
Can constraint properties include “state”? According to Roger only for integrator states. Note: that this would be the case in the Modelica Model if all the Modelica parameters were bound to properties
We use constraint parameters to represent “internal” variables (e.g., the position, s, of mass1model) — these variables are fully constrained through the model equations (e.g., v = der(s)), and should never be further constrained by binding them to other parameters. Is it acceptable to model these variables as constraint parameters?
The meaning of a binding connector in the diagram has been changed — it now reflects Kirchhoff semantics for flow variables. Is this acceptable? (it violates the strict semantics of a stereotype). What are the alternatives?

9. Questions for Discussion
Is it meaningful to bind structural properties to time-varying variables? It seems that the value of such a property would then be ill-defined or ambiguous outside a specific analysis context. If so, would it not make sense to define it only inside the analysis context?
In a «ModelicaModel» we using types defined in the Modelica Standard Library. In the structural model, we may use equivalent units/dimensions but defined as different ValueTypes. How do we best reconcile these differences?
Translating the current «ModelicaModel» into the Modelica language would require resolving all the bindings to external properties first. This may be difficult if there are complex relationships between these properties that need to be resolved first.
It is likely that certain properties in the structural model need to be bound to simulation results rather than model variables (e.g., the settling time of the suspension can only be determined through simulation). How do we best handle this?

10. Parametrics are not meant to carry state
We are defining the variables rather than just constraining them
Spring should really be called SpringEquation

11. Case 3: Modelica  IBD+PAR
Maintain value properties

12. Spring Mass System - IBD
Ask questions about the values of properties in Blocks and values in

13. Analysis Context for Spring Mass System - BDD

14. Spring Mass System - Parametrics
Same structure as ibd, but added constraints and represented flange properties
Much of this model would be abstracted away with SysML4Modelica stereotypes for constraining across and through variables