Webel: SysML/UML: Some example diagrams show extremely fine-grained and trivial examples purely for educational and capability demonstration purposes (not as practical recommendations for real-world projects). You can sometimes just use code in SysML.
MagicDraw/Cameo v19SP3: vs SysPhS-1.1: OpaqueExpression for Slot value exports to Modelica as 'null' if only uses a single variable. WORKAROUND/HACK prefix the variable with '1 *' [FIXED in v2021x]
SysPhS vs Modelica: If you redeclare a PhSConstant (Modelica parameter) as a PhSVariable (Modelica variable) Modelica still treats it as a 'parameter'. You can end up with an unbalanced system with one equation too many!
The targeting of the Modelica and Simulink simulation language families by the SysML Extension for Physical Interaction and Signal Flow Simulation (SysPhS) encourages development of SysML models aligned with known practices for a wide class of problems!
MagicDraw/Cameo v19SP3: vs SysPhS-1.1: Modelica export: Direct binding from a PhSVariable value property within a FlowProperty of a Port to an inner value property does not flatten. WORKAROUND: Use an intermediate constraint property.
SysML vs Modelica: GOTCHA: Terminology: A 'connector' in Modelica is equivalent to the Type of a Port in SysML. A Connector in SysML-1.x is equivalent to a 'connect(source,target)' in Modelica.
Webel vs SysPhS-1.1: Suggest SysPhSLibrary should explicitly support physical interactions with multiple conserved quantity flows. Example: Compressible fluid with mass and heat transfer.
Webel vs SysPhS-1.1: Suggest SysPhSLibrary should support Heat and FlowingHeat as conserved quantities with HeatFlowElement interface block and HeatFlowRate value type.
Webel vs SysPhS-1.1: Suggest SysPhSLibrary should support Mass and FlowingMass as conserved quantities (for compressible fluids) with MassFlowElement interface block and MassFlowRate value type.
MagicDraw/Cameo: Modelica export: Need environment option to disable generation of layout annotations (not just on individual export dialog)
MagicDraw/Cameo v19SP3+SysPhS-1.1: On export to Modelica sometimes repeats parts of an equation into an extending model.
MagicDraw/Cameo v19SP3+SysPhS-1.1: Does not cleanly export INLINE Modelica 'if/then/else' statements (a.k.a. "switching" form)
Webel vs SysPhS-1.1: Modelica: Suggest need option to NOT always set a 'start' value also as 'fixed' (especially where 'initial equation' is not supported)
SysPhS: MagicDraw/Cameo v19SP3: Export to Modelica does not interpret as 'start' the default on a PhSVariable assigned via ElementValue to a PhSConstant
MagicDraw/Cameo v19SP3: SysPhS: If you have a custom ValueType it MUST extend Real either directly or indirectly or it will not be seen on export to Modelica.
SysPhS-1.1: Does not support Modelica's 'initial equation'. WORKAROUND: One can often achieve the same by directly setting a default on a variable and/or by using additional variables/parameters with 'start' and additional equations.
SysML+SysPhS: Flows: If you intend to use a Classifier to type the itemProperty of an ItemFlow on a Connector for a physical interaction you MUST use a Block (not a ValueType or Signal) so your can extend ConservedQuantityKind.
In the Webel terminology for a basic control loop there is an 'aim' value (controlled via an actuator) and a 'got' value (a value read from a sensor). The 'got' value is NOT necessarily exactly the same as the actual physical value.
MagicDraw/Cameo v19SP3 vs SysML&SysPhS: Export to Modelica: The exported layout annotations appear to be completely broken (at least vs Wolfram SystemModeler) just de-select generation of them on export.
GOTCHA: MagicDraw SysML/Cameo 19SP3: Export to Modelica: The name of a redefining Property must be exactly the same as the Property it redefines or it will not export properly!
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Where ValueTypes involving litre are defined, the Unit symbol "L" is used rather than the Modelica-preferred "l" (in combination with an explicit additional unit converter).
Webel vs SysPhS-1.1: Annex A.5: Humidifier: The water temperature from TemperatureIncreaseConstraint and HeatingCalculationConstraint starts at 0 °C (should probably be the environment temperature 20 °C). Needs an additional parameter and initial value.
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Where custom ValueTypes are defined, Modelica-friendly Unit symbols are used. Examples: "m3" not "m^3"; "degC" not "°C"; "J/(K.L)" (full stop as multiplier) not "J/(K⋅L)"; (EXCEPT "L" for litre not "l").
Webel vs SysPhS-1.1: Annex A.5: Assume the conversion value property name 'SaturationVaporPressure::hPa2Pa' stands for 'hectopascal to pascal'.
Webel: SysML: DO NOT sacrifice modelling naming conventions for the mere sake of carrying organisation-specific names! Instead use tagged values of custom stereotypes as metadata to carry alternative names in parallel with systematic model element names.
Webel vs SysPhS-1.1: Annex A.5: Assume the conversion value property names 'WaterTank::litpSec2mLitpHr' and 'EvaporationCalculation2::litPSec2mLitPHour' stand for 'litres per second to millilitres per hour'
MagicDraw/Cameo: If you drag a Behavior from the model browser onto the SYMBOL of a State (that does not already own the Behavior) and set it as an 'entry', 'doActivity', or 'exit' Behavior a "wrapper" Behavior owned by the State will be created.
MagicDraw SysML/Cameo 19SP3: GOTCHA: If you drag a Behavior from the model browser onto the 'entry', 'doActivity', or 'exit' field in a specification dialog of a State it WILL BECOME OWNED by the State (which "steals ownership")!
MagicDraw/Cameo: Display options: On an 'entry', 'doActivity', or 'exit' Behavior of a State you may choose to display the specification code of an OpaqueBehavior or just its name.
Webel vs SysPhS-1.1: Annex A.5: Humidifier: In the Webel version it will be tentatively assumed we are in fact dealing with a large humidified space like an office building NOT a single "humidified room" - despite the block name HumidifiedRoom in the spec
Webel vs SysPhS-1.1: Annex A.5: Humidifier: If the WaterTank::tankVolume 50,000 is measured in litres (L) the VaporPressureCalculation::volume within the HumidifiedRoom can't possibly be 25000.0 litre (L), it has to be 25000.0 (m^3), which is NOT a "room"
Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that 'HumidityBalance::volume = 25,000' and 'VaporPressureCalculation::volume = 25,000' are the same fixed SpaceVolume in cubic metres (m^3).
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Dimensional analysis of VaporPressureCalculationConstraint implies each 1 mL of water is equated with EXACTLY 1 g of produced vapor.
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Dimensional analysis of VaporPressureCalculationConstraint implies the output is a pressure rate, which makes no sense as consumed by RelativeHumidityCalculation and is inconsistent with the rest of the system.
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Dimensional analysis of HumidityBalanceConstraint implies constraint parameter 'airExRate' in {change=((humidity-envH)*(volume*airExRate))} is per-volume, assuming that 'volume' is a fixed Volume.
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Dimensional analysis of RelativeHumidityCalculationConstraint implies constraint parameter 'change' in {der(x)=((press/satVap)-change)/c2} is a unitless relative humidity, given that 'c2' is a Time.
SysPhS-1.1: Annex A.5: The BDD Figure 74 and Parametric Diagram Figure 84 for block RelativeHumidityCalculationConstraint are missing PhSConstant 'c2'. Compare with the constraint {der(x)=((press/satVap)-change)/c2} in BDD Figure 79.
Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "vapor" is a volume rate corresponding to the rate of consumption OF HEATED LIQUID WATER (from a tank) used to create the vapor.
SysPhS-1.1: Annex A.5: p.89: Figure 75: Humidifier blocks, ports, & component properties. Typo in name of value property 'litpSec2mLiptHr:Real' on WaterTank should be 'litpSec2mLitpHr:Real' (breaks export of redefining Property with correct name).
MagicDraw/Cameo v19SP3 vs SysML&SysPhS: GOTCHA: Will NOT correctly export a SysML-1.6 «~interfaceBlock» to Modelica (but does cope with a tilde ~ prefix in the name of a plain InterfaceBlock)
MagicDraw/Cameo vs SysML&SysPhS: GOTCHA: Will NOT export a non-normative System «system» block to Modelica, it only recognises a plain Block «block»!
SysPhS-1.1: Annex A.5: Typo in Figure 98 redefining value property 'C2 : Time = 1.0{redefines C2,unit = second}', should be lower case 'c2' (compare with BDD Figure 79)
Sample problems and example diagrams in graphical language specifications are NOT necessarily indications of how one should model on a real-world project! They often just serve to demonstrate a particular aspect of the specified language.
Webel: UML/SysML: Navigation: ALWAYS offer a way out of a diagram (usually up a hierarchy, but possibly across) using a navigable symbol (linked to a diagram) and/or a diagram symbol. Avoid "cul-de-sacs"! [But beware of shared package cross-dependencies]
SysPhS-1.1: Annex A.5: 'Figure 101: Heating Scenario Initial Values': HeatingCalculation1: no such value to redefine 'C1 : Time = 1.0{redefines C1,unit = second}', should be 'xIntg : Real' (compare with BDD Figure 77 and Parametric diagram Figure 88)
SysPhS-1.1: Annex A.5: redefinition 'humidifierSystem {redefines humidifierSystem}' incorrect in Figure 96: Humidifier System Scenario Initial Values
SysPhS-1.1: Annex A.5: Humidifier: Constraints on HeatingCalculationConstraint not consistent between BDD Figure 79 and Par Figure 88 (does not have 'c1')
SysPhS-1.1: Annex A.5: Humidifier: Constraints on RelativeHumidityCalculationConstraint not consistent between BDD Figure 79 and Par Figure 84 (does not have 'c2')
SysPhS-1.1: Annex A.5: Humidifier: Use of UML-style direct Port conjugation not permitted since SysML-1.6, prefer ~InterfaceBlock type-based conjugation (example requires migration)
SysPhS-1.1: Annex A.5: Humidifier: Naming not very consistent across parts, input/output Port name, value properties, or constraint parameters
There is no «port» stereotype keyword for Port or Property in UML-2.5.1 or SysML-1.6. It is assumed to be introduced in some SysML and SysPhS specification diagrams as a custom or user-defined stereotype for special illustration purposes.
SysPhS-1.1: Apparent use of part Property with «port» keyword (instead of standard SysML Port) leads to property path symbols appearing inside the boundary of context blocks (instead of within a Port symbol on the boundary) in IBDs and Parametric Diagrams
Webel vs SysPhS-1.1: Recommend use standard SysML Ports instead of block part property with «port» keyword
MagicDraw/SysML vs SysPhS-1.1: Can't reproduce the "shortcut" property path representation of some properties nested within Ports as shortcut symbols fully inside the diagram frame. (Might be a specification diagram style issue.)
SysPhS-1.1: The correct ValueTypes should be used throughout instead of just Real for constraint parameters in 'Figure 61: Hydraulics model constraint blocks'
SysPhS-1.1: In the specification model for Figure 59 the handling of the initial values for some value properties (such as for 'gravity') in Tank usages within context block ConnectedTanks is WET not DRY (breaks Single Source of Truth).
SysML/SysPhS + Modelica: The variable 'time' is known to Modelica and need not be explicitly declared as a constraint parameter for a Constraint on a SysML ConstraintBlock
SysPhS-1.1 spec version of 'Figure 48: Internal structure of the signal processor' shows an ItemFlow for Real on an overlapping Connector line section, which is impossible to interpret.
Webel vs SysPhS-1.1: Diagramming style: DO NOT recommend overlapping Connectors with "phantom" fork (or junction) as shown in in 'Figure 48: Internal structure of the signal processor'
SysPhS-1.1: The correct ValueTypes for Current, Voltage, Resistance, Capacitance, and Inductance should be used throughout instead of just Real in 'Figure 40: Circuit constraint blocks'
SysPhS-1.1 spec version of 'Figure 38: Internal structure of the circuit example' shows some bi-directional ItemFlows for Charge on overlapping Connector line sections, which are impossible to interpret.
GOTCHA: A SysML/SysPhS Connector (or Modelica connection) in an electronics model is NOT a wire! It's a contract between connected Ports.
Webel vs SysPhS-1.1: Diagramming style: DO NOT recommend overlapping Connectors as shown in 'Figure 38: Internal structure of the circuit example'
SysPhS-1.1: TwoPinElectricalComponent in 'Figure 39: Electrical blocks, ports & component properties' could be marked abstract
SysPhS-1.1: Suggest use connector forms 'Modelica.Blocks.Interfaces.RealInput u;' and 'Modelica.Blocks.Interfaces.RealOutput y;' not 'input Real u;' and 'output Real y;' in Modelica code examples (otherwise not connectable).
SysPhS-1.1: p.38: 10.9.4 Modelica modeling, signal flow: Suggest kick start Spring with something like 'position=5' (otherwise get flat line when run).
SysPhS-1.1: p.38: 10.9.4 Modelica modeling, signal flow: Modelica code: the equation 'der(velocity)=(u-springcst*position)/m;' should use variable 'mass' not 'm'
SysPhS-1.1: p.60: table for routing components: row for Switch: equivalents Modelica.Blocks.Logical.Switch (for Modelica) and Switch (for Simulink) missing
SysPhS-1.1: Use of 'Criteria = u2~=0' for Simulink for Real.Routing.Switch::u2 inconsistent with BooleanInput of control port Modelica.Blocks.Logical.Switch::u2
SysPhS-1.1 (and MDSysML/Cameo 19SP3 SysPhSLibrary): Use of RealSignalInElement for Real.Routing.Switch::u2 inconsistent with BooleanInput of control port Modelica.Blocks.Logical.Switch::u2
MDSysML/Cameo 19SP3: SysPhSLibrary vs SysPhS-1.1: SourceAndSink.Constant: Wrong Real (UML version not SysML version) has been used for 'k', so sorts in the 'properties' compartment instead of the 'values' compartment
SysPhS-1.1: p.57: Table 11.3.2.5 Mathematical components: Modelica Parameters for the Subtraction row should indicate (k1 and) k2 required to achieve subtraction via Math.Add (or the correct exported values should be explained).
MDSysML/Cameo: SysPhSLibrary: GOTCHA: You must set the additional 'k2' parameter for Modelica to be minus to achieve subtraction
SysPhS-1.1: p.57: GOTCHA: Table 11.3.2.5 Mathematical components: Mathematical.Subtraction maps to Math.Add (in Modelica) and Sum (in Simulink)
MDSysML/Cameo 19SP3: SysPhSLibrary vs SysPhS-1.1: Mathematical.Subtraction: Wrong Real (UML version not SysML version) has been used for 'k2', so sorts in the 'properties' compartment instead of the 'values' compartment
MDSysML/Cameo 19SP3: SysPhSLibrary vs SysPhS-1.1: Mathematical.Gain: Wrong Real (UML version not SysML version) has been used for 'gain', so sorts in the 'properties' compartment instead of the 'values' compartment
MDSysML/Cameo 19SP3: SysPhSLibrary vs SysPhS-1.1: SPELLING/TYPO: VariableDelay: parameter 'maxDelay' should be 'delayMax'
MDSysML/Cameo 19SP3: SysPhSLibrary vs SysPhS-1.1: NonLinear.Saturation: Wrong Real (UML version not SysML version) has been used for 'lower' and 'upper', so sorts in the 'properties' compartment instead of the 'values' compartment
MDSysML/Cameo 19SP3 vs SysPhS-1.1: The Continuous.TransferFunction and Discrete.TransferFunction have Ports 'u : RealVectorSignalInElement [1]' or '[*]' and 'y : RealVectorSignalInElement [1]' or '[*] instead of RealSignalInElement/RealSignalOutElement
SysPhS: MagicDraw/Cameo: In the sysphs_profile the properties for PhSVariable have multiplicity [1], so the defaults always appear explicitly (but may be overridden): isContinuous: Boolean = true, isConserved: Boolean = false, changeCycle: Real = 0
SysPhS-1.1: p.30: text and Figure 22: Incorrect references to 'RealInSignalElement' and 'RealOutSignalElement' (should be RealSignalInElement, RealSignalOutElement)
SysPhS-1.1: p.53: Figure 30: Incorrect references to RealInSignalElement, RealOutSignalElement, IntegerInSignalElement, IntegerOutSignalElement, BooleanInSignalElement, BooleanOutSignalElement (should be RealSignalInElement, RealSignalOutElement, ...)
SysML: HOWTO Safely incorporate ConstraintBlock equations from a library into a project with local ValueType variants: CASE: SysPhS vs ISO-80000 ModelLibrary
SysPhS-1.1: p.47: 10.12.2 SysML modeling: The states StandBy and On in 'Figure 29: State machine in SysML' should probably use 'entry' not 'doActivity'.
SysPhS-1.1: When RealSignalInElement or RealSignalOutElement are used to type a SysML Port, assignments to the FlowProperty 'rSig' map to the Port name (only) when mapped to Modelica.
SysPhS-1.1: p.47: 10.12.2 SysML modeling: References to 'u.sigsp' and 'y.usigsp' should be 'u.rSig' and 'y.rSig'.
SysPhS-1.1: p.47: 10.12.2 SysML modeling: TYPO: Incorrect spelling of RealInSignalElement (should be RealSignalInElement) and RealOutSignalElement (should be RealSignalOutElement)
GOTCHA: MD SysML/Cameo 19SP3 vs SysPhS-1.1: Export to Modelica does not see a 'doActivity' on a State (does not write it to a Modelica algorithm), you MUST use an 'entry'!
SysPhS-1.1: 10.12.2 SysML modeling: p.47, p.48: References to .sig and .rsig in 'Figure 29: State machine in SysML' and Modelica code example should be .rSig
SysPhS-1.1: 10.12.2 SysML modeling: p.47: Name of StateMachine in 'Figure 29: State machine in SysML' should be ComputerSM (not Computer) for consistency with the Modelica code example
SysPhS-1.1: p.45: 10.11.2 SysML modeling: Reference to 'the units library in Figure 20, Subclause 11.2.2' is wrong
SysPhS-1.1: p.44: 10.10.3 Modelica modeling: Reference to 'The following Modelica code corresponds to Figure 15' should probably be 'to Figure 27'.
SysPhS-1.1: p.42: 10.9.8 Modelica modeling, physical interaction: Modelica code has 'forcediff=springcst*lengthchg;' should be 'forcethru=springcst*lengthchg;'
GOTCHA: MagicDraw SysML/Cameo 19SP3: Export to Modelica: 'entry', 'doActivity', or 'exit' Behaviors of a State must be directly owned (not just "wrapped") or they won't be seen on export!
SysPhS-1.1: p.41: 10.9.8 Modelica modeling, physical interaction: Reference to 'the bindings in Figure 14' should probably be 'the bindings in Figure 26'.
SysPhS-1.1: Typos: Numerous references to 'rsig' lower case should be 'rSig' (including Figure 25 and Figure 29)
SysPhS-1.1: p.38: 10.9.4 Modelica modeling, signal flow: Modelica code: the keyword should be 'equation' not 'equations'.
SysPhS-1.1: p.38: 10.9.4 Modelica modeling, signal flow: Example Modelica model should be for SpringMassSys not Spring
SysPhS-1.1: [TRIVIAL] p.11: If property 'm:Mass' is named then ':Ground' should also be named for consistency in 'Figure 2: Association block with internal structure and connector properties in SysML'
SysPhS-1.1: p.28: 10.6.3 Modelica modeling: An assigned value “...” is shown for v3 in the Modelica code but none is shown in the SysML model in 'Figure 21: PhSVariables and PhSConstant in SysML' (and “...” is not compatible with Real).
MagicDraw SysML/Cameo: 19SP3: Does not seem to support export to Modelica from a Package [use a SysML Block as root instead]
MagicDraw SysML/Cameo: SysPhS: Export to Modelica: It does not seem to matter whether you give the language of Constraints as 'Modelica' or 'sysphs' (although SysPhS specifies a restricted SysPhS expression grammar)
MagicDraw SysML/Cameo: GOTCHA: Export to Modelica only includes owned Constraints (not just applied Constraints) under the 'equation' export
SysPhS-1.1: p.32: 10.7.8 Modelica modeling, physical interaction: Type Real for 'f' and 'lV' in example Modelica code for Spring do not correspond to 'Figure 23: Ports for physical interaction in SysML', should be Force and Velocity.
SysPhS-1.1: p.30: 10.7.4 Modelica modeling, signal flow: Example Modelica code for Spring corresponding to 'Figure 22: Ports for signal flow in SysML' is invalid [should probably be 'input Real u;' and 'output Real y;' not 'in ...' and 'out ...']
MagicDraw SysML/Cameo: 19SP3: Export to Modelica from TestBed (for SignalProcessor) sample does not validate in Wolfram SystemModeler
MagicDraw SysML/Cameo: 19SP3: Export to Modelica from SysPhS sample for HumidifierSystem does not execute in Wolfram SystemModeler Simulation Centre
Webel Best Practice: SysML/SysPhS: DO NOT use overlapping Connector lines from/to one Port (can be misunderstood as "summed" flow and/or physical node/fork/junction).
MagicDraw SysML/Cameo: For export of more complex physical interaction and flow cases to Modelica or Simulink/Simscape/Stateflow load the SysPhS ModelLibrary using SysPhSLibrary.mdzip as a shared project.
MagicDraw SysML/Cameo: You do not always need to load the entire SysPhS ModelLibrary for simpler black box exports to Modelica or Simulink/Simscape/Stateflow (sometimes the sysphs_profile within the MD Customization for SysML is enough)
