1. SysML-Modelica Integration Working Group Report (SE DSIG meeting, Washington DC 3/24/2009) Chris Paredis Georgia Tech 1

2. Agenda Introductions Getting Organized Quick overview of initial draft document Discussion of Chapter 1 – Semantics of ports and connectors – Mock-ups for SysML equivalent of spring-mass system 2

3. Getting Organized Practical issues – Regular meeting slot: Wed at 10AM Eastern – Conference call facilities? Wiki – http://www.omg.org/members/sysml-rtf- wiki/doku.php?id=rtf2:groups:sysml_and_modelic a_integration (requires regular OMG password) http://www.omg.org/members/sysml-rtf- wiki/doku.php?id=rtf2:groups:sysml_and_modelic a_integration 3

4. WG Focus and Scope Focus: – Reuse Modelica syntax by Integrating Modelica into SysML – Integrating parts of SysML into Modelica may also be worth considering, but is outside the scope of this exercise Scope: – Cover the Modelica constructs needed for the Modelica Standard Library to be used in SysML – Generate corresponding SysML constructs that fit within the profiling mechanism 4

5. Overview of Draft Document 5

6. Main Question: Which Diagram Type? All three SysML diagrams share the same high-level structure – Composition of “port-based” objects – Connections between “ports” – Hierarchical: composition and “port” delegation 6 Rotational Energy Flow Signal Connection RealInput Connector

7. Semantics of Modelica Connectors 2 basic types: causal and acausal Causal: – defined as input or output Acausal: – defined as flow or nonflow (must appear in pairs of flow and nonflow) Basic types can be combined and nested into complex connectors 7

8. Semantics of Modelica Connections Defined by “connect(.,.)” statement – no direction: “connect(a,b)” same as “connect(b,a)” For causal connectors – Connection means Assignment – Input := output For acausal connectors – Connection means Kirchhoff’s Laws – Equality for nonflow: connA.voltage = connB.voltage; connB.voltage = connC.voltage – Conservation for flow: connA.current + connB.current + connC.current = 0; 8

9. Comments Only “connectors” can be connected – A connector is a specialized class – The designation of connector is thus part of the definition, not of the property (usage) In Modelica, there is no direct equivalent to SysML constraint parameters – Although acausal (binding) connections exist in Modelica, they can only be used together with a corresponding flow variable to express energy flow Modelica also differentiates based on “variability” – Constant: never changes (can be compiled in) – Parameter: value can be changed after compilation but is constant during simulation – Variable: value can change during simulation 9

10. Compared with ACT ACT object nodes: – (buffered) in/outputs of tokens – tokens could be continuously streaming to reflect energy flow Directed token-flow is not a good match Modelica semantics 10

11. Compared with IBD Similar: – Flow ports are similar to Modelica Connectors – could indicate the flow of signals and/or energy Different: – in/out/inout refers to direction of flow (sign of flow variable), not causality – in/out/inout are defined for port properties (usage) while in Modelica input/output/flow is defined in the connector definition (not usage) – Connections are typed and directed in SysML while untyped and undirected in Modelica 11

12. Compared with PAR Similar: – Parameters are similar to Modelica Connectors – (Binding) connections are untyped and undirected as in Modelica Different: – Currently only acausal parameters in SysML — an issue is pending to add input/output causality – A Modelica connector is a Class not a property – No notion of flow in SysML — no notion of Kirchhoff’s current law in the corresponding connections 12

13. Mock-ups 1.Modelica  IBD (Chris, Peter, Wladimir) 2.Modelica  PAR (Chris) 3.Modelica  IBD+PAR (Sandy) 13

14. Case 1: Modelica  IBD 14 Equivalent Modelica Model Note: Equations are captured as constraints in the «ModelicaModel» blocks

15. 15

16. Case 2: Modelica  PAR 16 Equivalent Modelica Model Note: Not all constraint parameters are shown

17. 17

18. Case 3: Modelica  IBD+PAR 18

19. Spring Mass System - IBD 19

20. Analysis Context for Spring Mass System - BDD 20

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

22. Discussion No perfect match -- Simplicity versus explicitness in semantics What are the reusable models?  to support reuse, we should create SysML structures that match the reusable model structures 22