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”

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

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

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

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.

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

We could

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?

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?

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

Case 3: Modelica  IBD+PAR Maintain value properties

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

Analysis Context for Spring Mass System - BDD

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