1 / 14

Integration Working Group Meeting Notes: SysML.Modelica Integration, Organizational, Semantic Comparison, Conclusions

This document contains the notes from the Integration Working Group Meeting discussing SysML.Modelica integration, organizational matters, semantic comparisons, and conclusions.

pietrzak
Download Presentation

Integration Working Group Meeting Notes: SysML.Modelica Integration, Organizational, Semantic Comparison, Conclusions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SysML Modelica IntegrationWorking Group Meeting 3/4/09 Chris Paredis

  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 EquivalentModelicaModel • 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

  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

  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. 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?

  8. 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?

  9. Case 3: Modelica  IBD+PAR

  10. Spring Mass System - IBD

  11. Analysis Context for Spring Mass System - BDD

  12. 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

More Related