SysPhS-1.1

Icon class
icon_class
far fa-file-alt
icon_class_computed
far fa-file-alt
Keywords
Specification keywords
SysPhS-1.1
Copyright information
About Object Management Group copyright in text extracts quoted from OMG specifications for educational purposes
Snippets (quotes/extracts)
SysPhS-1.1: This specification: Extends SysML with additional information needed to model physical interaction and signal flow simulation independently of simulation platforms.
SysPhS-1.1: This specification: Provides a human-usable textual syntax for mathematical expressions.
SysPhS-1.1: This specification: Includes a platform-independent SysML library of simulation elements that can be reused in system models.
SysPhS-1.1: This specification: Gives translations between SysML as extended above and two widely-used simulation languages and tools for physical interaction and signal flow simulation.
10.6.3 Modelica modeling: The variability of Modelica properties are of four kinds: continuous, discrete, parameter, and constant.
By default, Modelica properties are continuous. PhSVariables with isContinuous=true correspond to continuous components, PhSVariables with isContinuous=false correspond to discrete components, and PhSConstants correspond to parameter variables.
The following Modelica code corresponds to Figure 22. It has a model Spring, with two components u and y of type Real and of direction respectively in and out.
The following Modelica code corresponds to Figure 23. It has a model Spring, with two components p1 and p2 of type Flange. Flange is a connector that has one flow component f, and one regular component lV.
Connectors typed by association blocks, including their connector properties, are replaced by the internal structure of the association blocks. Figure 3 shows the content of Figure 2 after processing.
The connector and its property fa in Figure 2 is replaced by the content of the association block FrictionAssociation (the connector and its property and association block are removed).
The flange of the mass and the flange of the ground replace the participant properties of the association block and are connected to the property f of type Friction in the same way as in the association block
The following Modelica example corresponds to the SysML block A in Figure 18. It has a Modelica model A corresponding to the SysML block A, with a component b1 typed by Modelica model B, corresponding to the SysML property b1 typed by block B.
The following Modelica code corresponds to Figure 19. It has a model A with a component c1 of type C, and a model B that extends A. As a result, B inherits the component c1 from A.
The following Modelica code corresponds to Figure 20. It has a model A with component c1 indicated as replaceable, and a model B extending A with a component of the same name redeclaring it to alter the type ...
SysML packages correspond to Modelica models defined as the root element of a file. The following Modelica code corresponds to Figure 17. It has a model P owning a model B ...
The following Modelica code corresponds to Figure 21. It has a model A, with three properties v1, v2 and v3 of type Real, that are continuous, discrete, and parameter, respectively.
SysML connectors correspond to Modelica connect equations, which link components typed by Modelica connectors. This depends on the correspondence between SysML port types and Modelica connectors ...
The following Modelica code corresponds to Figure 24. It has a model Example with two components s1 and s2 of types SpringA and SpringB, respectively. The models SpringA and SpringB have two components p1 and p2 of type Flange, defined similarly to Spring
Model [ERROR] contains a connect equation linking component p2 of s1 to component p1 of s2.
In a SysML block with constraint properties, the constraints correspond to the same equations in Modelica ... except the SysML parameters in those constraints correspond in Modelica to the properties they are bound to in SysML.
The following Modelica code corresponds to Figure 25. It has three equations from the constraint block.
SysML parameter names are replaced in the Modelica equations according to the bindings in Figure 13 [ERROR]: f is replaced by u, pos is replaced by y, x is replaced by position, k is replaced by springcst, v is replaced by velocity, m is replaced by mass.
In a SysML block with constraint properties, the constraints correspond to the same equations in Modelica ... except the SysML parameters in those equations correspond in Modelica to the properties they are bound to in SysML
(and flow properties in SysML property paths leading to PhSVariables on conserved quantity kinds are omitted in Modelica, see Subclause 10.7.8).
The following Modelica code corresponds to Figure 26. It has five equations from the SysML constraint block. SysML parameter names are replaced in the Modelica equations according the bindings in Figure 14 [ERROR]:
f1 is replaced by p1.f, v1 is replaced by p1.lV, x is replaced by lengthchg, k is replaced by springcst, v is replaced by velocitydiff, f is replaced by forcethru, v2 is replaced by p2.v, and f2 is replaced by p2.f.
SysML default and initial values correspond to start values of Modelica components. Start values are marked as fixed, requiring the values be set at the beginning of the simulation (otherwise, simulators only take the values as suggestions ...)
The following Modelica code corresponds to Figure 15 [ERROR].
It has a model B with a val component. The val component has a start value of 10. A class A is defined with a component b of type B. A component modification indicates that the start value of b.val is 20.0.
Data types in SysML are called value types.
SysML numeric value types can be linked to units, where units are modeled with the SysML Unit block. These units are linked to value types that are generalized by SysML’s numeric value types. Units and their symbols are from ISO 80000.
Figure 28 shows how a value type with units is defined in SysML, from the units library in Figure 20 [ERROR], Subclause 11.2.2 [ERROR]. It has a value type Force that specializes the Real value type and has newton as unit. The newton unit has a symbol N.
Modelica data types can be subtyped to add a unit symbol. The interpretation of this symbol is not defined in Modelica.
The following Modelica code corresponds to Figure 28. It has a type Force, which extends Real, and the unit symbol N assigned to it.
The following Modelica code corresponds to Figure 29.
Computer has ports u and y of type RealInSignalElement [ERROR:TYPO] and RealOutSignalElement [ERROR:TYPO] from the signal flow library (see Subclause 11.2.1), respectively.
The state machine has one initial pseudostate, and two states StandBy and On.
The transition from the initial pseudostate to StandBy has a relative TimeEvent with an expression indicating that the transition fires 5 seconds after the initial pseudostate is entered.
The transition from StandBy to On has a ChangeEvent with an expression indicating that the transition is triggered when u.sigsp [ERROR] is equal to 1 (this is a signal as in signal flow simulation, not as in SysML).
The transition from On to StandBy has a ChangeEvent with an expression indicating that the transition is triggered when u.sigsp [ERROR] is equal to 0.
When the computer is in StandBy, y.sigsp [ERROR] is set to 8, and when the computer is On, y.sigsp [ERROR] is set to 3.
Figure 22 shows an example signal flow application. The block Spring has two ports u and y, of type RealInSignalElement and RealOutSignalElement from the signal flow library ..., respectively.
RealInSignalElement has an in flow property rsig, while RealOutSignalElement has the same property with an out direction.
Simulation platform data specified in the Component Ports (Input and Output), PhSConstants, and platform Parameters columns are scalar, unless marked with a V (vector) or an M (matrix).
Component input ports for scalars are typed by RealSignalInElement, IntegerSignalInElement, or BooleanSignalInElement, while component output ports for scalars are typed by RealSignalOutElement, IntegerSignalOutElement, or BooleanSignalOutElement ...
Component input ports for vectors are typed by specializations of RealVectorSignalInElement, while component output ports for vectors are typed by specializations of RealVectorSignalOutElement ...
Component PhSConstants (SimulinkParameters and ModelicaParameters) for vectors and matrices have MultidimensionalElement applied, with dimension * and *,*, respectively ...
11.5.2 Platform profile: This subclause defines stereotypes that Subclause 11.3 applies to the base classes and properties (including ports) of its blocks, to specify which library elements of Modelica and Simulink correspond to them.
A PhSConstant has values that do not change during simulation runs. Values can change between simulation runs.
A PhSVariable has values that can vary over time in a continuous or discrete fashion.
Continuous variables have values that are close to their values at nearby times in the past and future. Discrete variables have values that are the same as their values at nearby times in either the past or future, or both.
PhSConstant: [1] Properties stereotyped by PhSConstant must be typed by Real, Integer, or Boolean, or one of their specializations.
PhSConstant: [2] Properties stereotyped by PhSConstant must have multiplicity 1, unless they are also stereotyped by MultidimensionalElement (see Subclause 11.5).
PhSConstant: [3] Properties stereotyped by PhSConstant must not redefine more than one other property, which must have the same name and type and must be stereotyped by PhSVariable or PhSConstant.
PhSVariable: [1] The stereotyped property must be typed by Real, Integer, or Boolean, or one of their specializations.
PhSVariable: [2] isContinuous may be true only when the stereotyped property is typed by Real or one of its specializations.
PhSVariable: [3] isConserved may be true only when isContinuous is true and the stereotyped property is on a block specialized from ConservedQuantityKind (see Subclause 11.2.2).
PhSVariable: [4] changeCycle may be other than 0 only when isContinuous is false.
PhSVariable: [5] changeCycle must be positive or 0.
Figure 25 shows an example [USAGE OF A] constraint block for a signal flow application, using ports like those defined in Figure 22, Subclause 10.7.3, except in a system containing a spring attached to another object.
The block SpringMassSys has a SysML constraint property smsc typed by SMSConstraint. The constraint block has six parameters, each bound to a property reachable from the spring mass system:
A.2.2 System being modeled: The electrical circuit has six components: ground, electrical source, inductor, capacitor, and two resistors, see Figure 37.
Equations define mathematical relationships between the values of numeric variables. Equations in SysML, are constraints in constraint blocks that use properties of the blocks (parameters) as variables.
In this example, a constraint block BinaryElectricalComponentConstraint defines parameters and constraints common to resistors, inductors, capacitors, and sources, as shown in Figure 40.
These specify that the voltage v across the component is equal to the difference between the voltage at the positive and negative pins. The current i through the component is equal to the current going through the positive pin.
The current i through the component is equal to the current going through the positive pin.
The sum of the current going through the two pins adds up to zero (one is the negative of the other), because the components do not create, destroy, or store charge.
The constraints for the resistor, capacitor, and inductor specify the voltage/current relationship with resistance, capacitance, and inductance, respectively.
The source constraint defines the circuit’s electrical source. The ground constraint specifies that the voltage at the ground pin is zero.
The source constraint defines the voltage across it as a sine wave with the parameter amp as its amplitude.
A.3.2 System being modeled The signal processor and its testbed have a wave generator, an amplifier, high-pass and low-pass frequency filters, a mixer, and a signal sink, see Figure 46.
Figure 47 and Figure 48 show the internal structure of blocks TestBed and SignalProcessor, respectively
Part properties, typed by blocks ... represent the components of the system. They are connected through ports .. which represent signal outputs and inputs ...
Signals pass through ports in the direction shown by the arrows. Item flows on connectors indicate that the signals are real numbers.
Figure 47 connects a signal source to a signal processor, which it connects to a signal sink that displays the output.
Figure 48 connects the signal processor input to an amplifier, the output of the amplifier to a high-pass filter in parallel with a low-pass filter, the outputs of the filters to a mixer, and the output of the mixer to the signal processor output.
SysML initial values specify property values for components used in internal block diagrams.
Figure 47 shows an initial value for source amplitude amp, while Figure 48 shows initial values for amplifier signal gain g and filtering properties xi and alpha ...
Figure 49-Figure 50 show block definitions for components of TestBed and SignalProcessor in Figure 47 and Figure 48, respectively.
The output for SignalSource is named y and is typed by RealSignalOutElement, from the signal flow library ...
The input for SignalSink is named u and is typed by RealSignalInElement, also from the library. The signal processor has an input and output, transforming the signal from the source and passing it to the sink.
In Figure 50, amplifiers, low-pass filters, and high-pass filters, each have an input and an output. Since they are similar in this sense, a generalized TwoPinSignalComponent component has an input u and an output y.
Mixers have inputs u1 and u2, and an output y.
Signal flow is the movement of numbers between system components. These numbers might reflect physical quantities or not. In this example, they do not ...
Each kind of component has its own behaviors, defined as constraints ...
Signals flowing in and out of components are modeled by ports typed by interface blocks that have flow properties typed by numbers.
In this example, ports are typed by RealSignalOutElement and RealSignalInElement from the signal flow library ... which both have a flow property rSig typed by Real, from SysML, as shown in Figure 49.
This value type has no unit, reflecting that the signals are not measurements of physical quantities and do not follow conservation laws.
The amplifier, filters (high-pass and low-pass), signal source, and signal sink have properties g, alpha and xi, amp, and scope, respectively.
The amp, alpha and g properties have the PhSConstant stereotype applied, specifying that their values are constant during each simulation run.
The xi and scope properties have the PhSVariable stereotype applied, specifying that their values might vary during simulation.
Equations define mathematical relationships between the values of numeric variables. Equations in SysML, are constraints in constraint blocks that use properties of the blocks (parameters) as variables.
In this example, a constraint block BinarySignalComponentConstraint defines the parameters for one input (ip) and one output (op), common to amplifiers, low-pass filters, and high-pass filters, as shown in Figure 51.
The amplifier, low-pass fil[t]er, and high-pass filter constraints show the input-output relationship of these components as the signal passes through them.
The amplifier changes the signal strength by a factor gain, the low-pass filter eliminates the high-frequency components of the incoming signal, and the high-pass filter eliminates the low-frequency components of the signal.
The mixer constraint specifies the relationship between its one output and the two inputs that come from the low-pass and high-pass filters. The constraint defines the output to be the average of the inputs.
The source constraint specifies a sine wave signal with the parameter amp as its amplitude. The sink constraint displays (scopes) the output signal from the signal processor.
Equations in constraint blocks are applied to components using binding connectors in component parametric diagrams.
Component parametric diagrams show properties typed by constraint blocks (constraint properties), as well as component and port simulation variables and constants.
Binding connectors link constraint parameters to simulation variables and constants, indicating their values must be the same.
Figure 52 through Figure 57 show parametric diagrams for the source, amplifier, high-pass fil[t]er, low-pass filter, mixer, and sink, respectively.
A.4.2 System being modeled: The hydraulic system has three components: two fluid reservoir tanks and a pipe for connecting these tanks, see Figure 58.
A.4.1 Introduction: This subannex gives a model of a simple hydraulic system as an example of physical interaction (fluid flow). It does not include any signal flows
Figure 60 shows block definitions for components of ConnectedTanks in Figure 59.
Tanks and pipes have openings for fluid to pass through, one for tanks and two for pipes. The openings are represented by ports of type VolumeFlowElement, from the physical interaction library ..
Each type of component has its own behaviors, defined as constraints ...
Figure 59 shows the internal structure of a ConnectedTanks block.
Part properties, typed by blocks ... represent components in this system. They are connected to each other through ports, which represent openings in the tanks and pipe ...
Item flows on connectors indicate fluid passes through the ports and between the parts. The diagram connects a tank to each end of a pipe.
SysML initial values specify property values for components used in internal block diagrams. Figure 59 shows initial values for fluid density, gravity, tank surface area, pipe radius, pipe length, and dynamic viscosity of the fluid ...
An alternative for specifying initial values of part properties in the ConnectedTanks is to specialize it and redefine the part properties with default values for various configurations ...
Equations define mathematical relationships between the values of numeric variables. Equations in SysML, are constraints in constraint blocks that use properties of the blocks (parameters) as variables.
In this example, constraint blocks PipeConstraint and TankConstraint define parameters and equations for pipes and tanks, respectively, as shown in Figure 61.
The pipe constraints specify that the pressure pressureDiff across it is equal to the difference of fluid pressures opening1Pressure and opening2Pressure at each end of the pipe.
The fluid flow rate through the pipe, fluidFlow, is proportional to the pressure difference by the constant resistance, which depends on the geometric properties of the pipe as well as fluidic properties.
The magnitude of fluid flow rate through the pipe fluidFlow is the same as the magnitude of flow rates opening1FluidFlow and opening2FluidFlow going through the pipe’s openings, though the values differ in sign.
The sum of the fluid flow rates going through the two pipe openings is zero (the fluid is assumed to be incompressible).
The tank constraints specify that the pressure in the tank, pressure depends on the height of the fluid level in the tank, fluidHeight, as well as properties of the fluid, fluidDensity.
Also, the fluid flow in the tank, fluidFlow, is related to the change in the fluid height level fluidHeight over time and the cross-sectional surface area of the tank, surfaceArea.
Equations in constraint blocks are applied to components using binding connectors in component parametric diagrams.
Component parametric diagrams show properties typed by constraint blocks (constraint properties), as well as component and port simulation variables and constants.
Binding connectors link constraint parameters to simulation variables and constants, indicating their values must be the same.
Figure 62 and Figure 63 show the parametric diagrams of the tank and the pipe, respectively.
A.5.2 System being modeled: The total humidifier system has two main components: the humidified room and the humidifier, see Figure 64.
The humidifier uses information about the room’s humidity level to determine how much vapor to input to the room. The humidifier includes a water tank, a heater controller, and a vapor generation plant.
A.5.3 Internal structure: Figure 65 through Figure 71 show the internal structure of the total humidifier system and its components through seven nested internal block diagrams.
The internal structure of the block HumidifierSystem shown in Figure 65 uses the blocks HumidifiedRoom and Humidifier. These two blocks have their own internal structures.
The internal structure of HumidifiedRoom depicted in Figure 66 uses a block RelativeHumidity, which has an internal structure depicted in Figure 67.
The internal structure of Humidifier in Figure 68 uses a block VaporGenerationPlant, which has an internal structure shown in Figure 69.
The internal structure of VaporGenerationPlant uses blocks Heating and Evaporation, which have internal structures depicted in Figure 70 and Figure 71, respectively.
The blocks used in these diagrams are introduced in Subannex A.5.4.
A.5 Humidifier: A.5.1 Introduction: This subannex gives a model of a room humidifier as an example of signal flows and state machines.
Some signals in the example reflect physical quantities, but this is not physical interaction in the sense of physical substances with flow rates and potentials ...
External links
https://www.omg.org/spec/SysPhS/1.1/PDF
This is the source document tracking page. Visit also: SysPhS zone (SysML Extension for Physical Interaction and Signal Flow Simulation).
Visit also
Visit also (backlinks)
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!
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 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)
MagicDraw/Cameo v19SP3+SysPhS-1.1: Does not cleanly export Modelica 'when/then' statements
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)
SysPhSLibrary and ISO-80000 ModelLibrary: Some ValueType names and Unit symbols are not Modelica-friendly
SysPhS-1.1: Does not support Modelica's 'min' or 'max' on type declarations
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.
[IN PROGRESS] SysML+SysPhS vs Modelica By Example in MagicDraw SysML (or Cameo Systems Modeler)
IBD: Context for SimpleDomesticInverterAirCon - detailed
IBD: Context for SimpleDomesticInverterAirCon
Overview of two SysPhS-style physical interaction Port types
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 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'
Webel vs SysPhS-1.1: Annex A.5: Humidifier: The restriction of "vapor" to the range 0..1 in EvaporationCalculation2 seems completely arbitrary, it is NOT a ratio!
Webel vs SysPhS-1.1: Annex A.5: Humidifier: In EvaporationCalculation the specificHeat value 1.996 is off by a factor of about 2. It seems to have used the steam (gas) per gram value instead of the liquid water value per gram (or per mL volumetric) value.
Webel vs SysPhS-1.1: Annex A.5: Humidifier: Dimensional analysis of TemperatureIncrease and EvaporationCalculation implies the 'specificHeat' is a volumetric heat capacity, not a specific heat capacity (heat capacity per unit of mass).
Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is NOT assumed that the specification example is completely realistic (but an attempt is made to indeed interpret it as realistic using dimensional analysis and quantity magnitude checks).
Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "waterVolume" in TemperatureIncreaseConstraint is a rate litres per second (L/s), so it is named 'waterVolumeRate' in the Webel trail version.
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 "radiation" is a rate (equivalent to a power).
Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "energy" is a rate (equivalent to a power).
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).
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)
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: RelativeHumidityScenario1: Figure 98: Relative Humidiity Scenario Initial Values: RelativeHumidity should be RelativeHumidity1
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: p.81: 'resistance:ViscousResistance' (in Figure 60) has to be treated as a PhSVariable not a PhSConstant, otherwise get an invalid system with 6 variables and 7 equations.
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).
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 Annex A examples in MagicDraw SysML (or Cameo Systems Modeler) vs Modelica
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
Figure 36: Elements for vector signal flow
Figure 35: Simulation platform stereotypes
Figure 34: Value types and units for physical quantities
Figure 33: Value types and units for electrical quantities [including additional]
Figure 32: Elements for signal flows of electrical quantities [additional]
11.3 Component behavior - Electrical components
11.3 Component behavior - Logical components
11.3 Component behavior - Routing components
SysPhS-1.1: p.60: table for routing components: row for Switch: equivalents Modelica.Blocks.Logical.Switch (for Modelica) and Switch (for Simulink) missing
11.3 Component behavior - Sources and sinks
11.3 Component behavior - Real.Mathematical
11.3 Component behavior - Real.NonLinear
11.3 Component behavior - Real.Discrete
11.3 Component behavior - Real.Continuous
Figure 31: Elements for physical interaction
Figure 30: Elements for signal flow
SysML: HOWTO Use an explicit converter between different Unit systems
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: 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'!
Figure 29: State machine in SysML
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
Figure 28: Units in SysML
Figure 27: Default values and initial value in SysML
SysPhS-1.1: p.42: 10.9.8 Modelica modeling, physical interaction: Modelica code has 'forcediff=springcst*lengthchg;' should be 'forcethru=springcst*lengthchg;'
Figure 26: Constraint block for physical interaction in SysML
Figure 25: Constraint block for signal flow in SysML
Figure 24: Connectors in SysML
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'
Figure 23: Ports for physical interaction in SysML
Figure 22: Ports for signal flow 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).
Figure 21: PhSVariables and PhSConstant in SysML
Figure 17: Package and model in SysML
Figure 18, 19, 20: Block, Part, Generalization, Redefinition.
Figure 2: Association block with internal structure and connector properties in SysML (and Figure 3)
Figure 1: Simulation stereotypes
SysPhS-1.1 specification body figures in MagicDraw SysML (or Cameo Systems Modeler) vs Modelica
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)
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 ...']
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).