Webel's "super-relational" Note pages!

A Note is a short categorised statement, claim, policy, tip, or issue tracker Throughout this site, content is often related to supporting Notes, and each Note page links back to the content pages that reference it! The Note and Snippet concepts are very closely related and they support each other.
Look for "super-relational" Note page links at the bottom of most content pages!
Note kind Note Spec tag UML keywords SysML keywords Keywords
CONVENTION Webel: Psy/MPsy: Psychrometrics for Mathematica: For Imperial Units (IP), International British Thermal Units (Btu) are assumed Psychrometrics, energy, British Thermal Unit, Btu, Webel::Psy, Webel::MPsy
CONVENTION, NAMING Webel: Psy/MPsy: Psychrometrics for Mathematica: Equation registry with variable/quantity markup Psychrometrics, Webel::MPsy, Webel::Psy, humid air, water, liquid water, steam, gas, fluid, vapour, water vapour
CONVENTION Webel: Psy/MPsy: Psychrometrics for Mathematica: Due to Mathematica's units-aware Quantity algebra system it is irrelevant what units are used for the input Quantities for creation of the MPsy objects, as long as they are dimensionally consistent! Psychrometrics, Webel::Psy, Webel::MPsy, Mathematica, units, SI unit, Imperial unit, Mathematica::Quantity
NAMING, PATTERN, POLICY Webel: Psy/MPsy: Psychrometrics for Mathematica: Convention: Option variable names are prefixed with '$opt$psy' Webel Best Practice, Mathematica, Wolfram Language, naming, coding, Mathematica::option, Webel::MPsy, Webel::Psy
CONVENTION Webel: Psy/MPsy: Psychrometrics for Mathematica: Convention: 'Q' indicates the energy GAINED BY the system as heat energy transfer; 'W' indicates the work DONE BY the system on its external surroundings. Psychrometrics, Webel::MPsy, Webel::Psy, thermodynamics, heat, energy transfer, work, thermodynamic work
CONVENTION, NAMING Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$wat' indicates a water-related variable, quantity, or function (note that 'w' is reserved for the humidity ratio). Psychrometrics, Webel::MPsy, Webel::Psy, humid air, water, liquid water, steam, gas, fluid, vapour, water vapour, flow direction, flow
CONVENTION, NAMING Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$wat$i' indicates water (liquid or vapour) flow TO (into) the humid air mixture. A suffix '$wat$o' indicates water (liquid or vapour) flow FROM (out of) the humid air mixture. Psychrometrics, Webel::MPsy, Webel::Psy, humid air, water, liquid water, steam, gas, fluid, vapour, water vapour, flow direction, flow
CONVENTION, NAMING Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$sat' indicates a humid air mixture quantity at saturation (relative humidity = 1 or degree of saturation = 1). Psychrometrics, Webel::MPsy, Webel::Psy, humid air, water, vapour, water vapour, saturation, relative humidity, degree of saturation
CONVENTION, NAMING Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$ha' indicates a HUMID air mixture variable, quantity, or function or a PER humid air mass quantity. Psychrometrics, Webel::MPsy, Webel::Psy, humid air, water, liquid water, steam, gas, fluid, vapour, water vapour
CONVENTION, NAMING Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$g' in a water-related variable name refers to water vapour (a special case of gas) or steam. A suffix '$f' refers to liquid (fluid) water. [Although a gas is a fluid.] Psychrometrics, Webel::MPsy, Webel::Psy, humid air, water, liquid water, steam, gas, fluid, vapour, water vapour
CONVENTION, NAMING Webel: Psy/MPsy: Psychrometrics for Mathematica: A suffix '$a' indicates a DRY air component variable, quantity, or function. A suffix '$da' indicates a HUMID air mixture quantity PER dry air. Psychrometrics, Webel::MPsy, Webel::Psy, humid air, water, liquid water, steam, gas, fluid, vapour, water vapour
CONVENTION, LIMITATION, MODELLING, NAMING, TOOL Webel: Psy/MPsy: Psychrometrics for Mathematica: '$HC' in a function name indicates pure sensible heating or cooling (with no change in water vapour content). Such functions may also be used in the pure sensible portion of a 2-step treatment. SysML-1.6, SysML-1.7, UML-2.5.1 Activity, CallBehaviorAction, Action, Parameter, Activity Diagram, ObjectFlow, Pin, InputPin, OutputPin SysML Activity Diagram, MD:UNSPECIFIED Webel::MPsy, Webel::Psy, Psychrometrics, Mathematica
ASSERTION Webel: Programmers who can count higher than one (1) know that you don't have to choose exclusively between object-orientation (and classes) and functional programming. You can have your cake and eat it. It's not XOR! OO, OOP, object-oriented, functional, functional programming
EXPLANATION, MODELLING, TIP Webel: On going beyond SysML (and UML) with additional modelling practices, policies, and additional semantics SysML-1.6, SysML-1.7, UML-2.5.1 custom Stereotype, Stereotype, Profile SysML, Systems Modeling Language, UML, Unified Modeling Language, modelling, semantics, Webel Best Practice
CONVENTION, MODELLING, TIP Webel: MBSE: SysMLv1: Prefer a custom «actor» extension of a Block (such as the non-normative External) over UML-style Actor for use as parts in IBDs and on allocation swimlanes. You can also have a Trace from a block-based «actor» to a UML-style Actor. UseCase, Actor, Trace, «trace» SysML Use Case Diagram, Trace, «external», SysML Internal Block Diagram, custom block-based «actor», swimlane, AllocateActivityPartition, Allocate, SysML Activity Diagram, part property, ActorPart, MD:Customiz Systems Modeling Language, SysMLv1, SysML, MagicDraw SysML, Cameo Systems Modeler, Webel:«actor:internal»
LIMITATION, TOOL, WISHLIST Webel: Mathematica: WISHLIST: Support for EXTRACTABLE structured documentation for individual arguments to functions RIGHT IN/NEAR THE CODE. Yes it is needed. Really it is. Wolfram, Mathematica, Webel:WISHLIST
TOOL, WISHLIST Webel: Mathematica: WISHLIST: Support for decent vendor-supported, built-in, fully fledged, IDE-friendly, object-orientation (OO)! [With or without the use of state, which is a choice, not obligatory, and OO doesn't throw functional away] Wolfram, Mathematica, Webel:WISHLIST, inheritance, object-oriented, OOP, OO
CONVENTION, NAMING, PATTERN, STYLE, TIP Webel: Mathematica: TIP: Maintain a Package library of Quantity variables for frequently used units using a naming convention unit$[unitSymbol] and unit[DescriptiveName] or unit[Acronym] Wolfram, Mathematica, SI unit, quantity, units, Webel Best Practice, Mathematica::Quantity
ASSERTION, TIP Webel: Mathematica is functional programming on steroids (and has nearly everything else, except for decent in-built OO support, although you can make some progress with Abstract Data Types and even some inheritance). Mathematica, Wolfram, functional programming, functional
MODELLING, STYLE, TIP Webel: MagicDraw/Cameo: UML/SysML: TIP: Activity Diagrams, StateMachine Diagrams, and port-based IBDs: Keep it loose initially with oblique (no break) paths, then square it up with rectangular paths at the very end SysML-1.6, SysML-1.7, UML-2.5.1 StateMachine Diagram, Activity Diagram, Activity, StateMachine, Pin, Port SysML Activity Diagram, SysML Internal Block Diagram MagicDraw, Cameo Systems Modeler, UML, SysML, MagicDraw SysML, CATIA Magic, Systems Modeling Language, Unified Modeling Language, Webel Best Practice
ASSERTION, DISPLAY, FEATURE, SETTINGS, TIP, TOOL Webel: MagicDraw/Cameo: STRONGLY RECOMMEND: On EVERY project of ANY kind set the Environment Perspective to 'Full Featured' and check the Expert box, even if you are a "novice". For SysML use 'Full-Featured' not just 'System Engineer'! Cameo Systems Modeler, MagicDraw UML, MagicDraw SysML, SysML, Webel Best Practice
ASSERTION, DISPLAY, FEATURE, MODELLING, SETTINGS, TIP, TOOL Webel: MagicDraw/Cameo: Set EVERY element properties & symbol properties filter to 'All' (yes, not just 'Expert', to 'All', even if you are a "novice" on your first project) in EVERY dialog and every project option setting. Use the search filters! SysML-1.6, SysML-1.7, UML-2.5.1 Cameo Systems Modeler, MagicDraw UML, MagicDraw SysML
DISPLAY, SETTINGS, STYLE, TOOL Webel: MagicDraw/Cameo: First recommended display style settings and project option steps for every SysML (and UML) project. [Includes TIP: DO NOT show the Diagram Name in the optional Diagram Info adornment, show it on the Diagram frame only] Webel Best Practice, MagicDraw SysML, MagicDraw UML, Cameo Systems Modeler, Magic Model Analyst [Cameo Simulation Toolkit]
ANTI-PATTERN, NAMING, POLICY Webel: In some SysML trails ValueType names with Unit indicator suffixes have been used for dimensional analysis and illustrative purposes. This practice is NOT otherwise recommended here. Instead just use consistent custom ValueTypes across your system! SysML-1.6, SysML-1.7, SysMLv2 ValueType Webel Best Practice
CONVENTION, MODELLING, NAMING, TIP Webel: If you must name your Ports or Pins, name them simply 'i', 'o', or 'io' to indicate direction UNLESS you have to indicate a special role like 'iRole', 'oAuxiliary'. DO NOT use Port or Pin names like 'input', 'output', etc. SysML-1.6, SysML-1.7 Port, Pin, NamedElement::name Webel Best Practice
NAMING, POLICY Webel: For SysML Blocks and InterfaceBlocks used to type Ports with physical flows use 'F_UpperCamelCase' [may be combined with acronymn conventions Port Block, InterfaceBlock, FullPort, ProxyPort, "standard" Port, flow, FlowProperty SysML
ASSERTION Webel: Dr Darren says: "Many aspects of older Document-Intensive Systems Engineering methodologies and the reporting obligations they impose on their users were intended to address problems that simply DO NOT EXIST ANYMORE with modern MBSE with SysML!" SysML-1.6, SysML-1.7, SysMLv2 SysML, Systems Modeling Language, SysMLv1, MBSE, Model-Based Systems Engineering, Webel Best Practice
ASSERTION, MODELLING, TIP Webel: Domain Modelling in graphical SysML (and the best SysML tools) is massively, hugely, compellingly, better than in any other language (or tool). [OWL does something very useful but different.] SysML, Systems Modeling Language, SysMLv2, SysMLv1.x
CONVENTION, NAMING Webel: DO NOT name the Type (Block or InterfaceBlock) of a Port with a flow the same as the name of the 'Stuff' that flows through it; use the Webel 'F_Stuff' convention! Port FlowProperty, InterfaceBlock, ~InterfaceBlock, Block Webel Best Practice
CONVENTION Webel: Convention: [MIGHT CHANGE]: An '@' prefix in a DigitalTwin model indicates a «digital» Block that maps a non-digital «mappable» Block. Webel Best Practice, Webel Twin Pattern
ISSUE, LIMITATION, TOOL, WARNING Webel: Cameo Simulation Toolkit v19SP3/v2024x: Could not get ReclassifyObjectAction to work (yet) SysML-1.6, SysML-1.7, UML-2.5.1 ReclassifyObjectAction fUML, Magic Model Analyst [Cameo Simulation Toolkit], SysML, CATIA Magic:v2024xGolden
POLICY Webel: A plain Dependency that is not stereotyped is always strictly timed-ordered; the supplier (target) must exist before the client (source). SysML-1.6, UML-2.5.1 Dependency, Dependency::supplier, Dependency::client, DirectedRelationship::/source, DirectedRelationship::/target
NAMING, STYLE Webel: "Trust the Metaclass or Stereotype" of an Element to indicate what type of element it is (you don't have to repeat it in the name) NamedElement::name Webel Best Practice
POLICY, STYLE Webel «pa» Parsing Analysis Diagrams (PADs) are "scratchpads" used to elicit model elements traceably from text Snippets (extracts from source Documents). While BDDs are a good initial choice, most types of SysML diagram can be used as a «pa» diagram. Webel Parsing Analysis, parsing analysis, WPA:«pa»
PROPOSAL 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. SysPhS-1.1 Block, InterfaceBlock, ValueType SysPhS, mass, fluid flow, compressible fluids
PROPOSAL Webel vs SysPhS-1.1: Suggest SysPhSLibrary should support Heat and FlowingHeat as conserved quantities with HeatFlowElement interface block and HeatFlowRate value type. SysPhS-1.1 Block, InterfaceBlock, ValueType SysPhS, heat, thermodynamics
PROPOSAL 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. SysPhS-1.1 Block, InterfaceBlock, ValueType SysPhS, mass, fluid flow, compressible fluids
MODELLING, STYLE Webel vs SysPhS-1.1: Recommend use standard SysML Ports instead of block part property with «port» keyword SysPhS-1.1 «keyword», Port, Stereotype "standard" Port, block property, part property SysPhS
ISSUE, PROPOSAL 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-1.1 Property::defaultValue SysPhS
ANTI-PATTERN, WARNING 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' SysML-1.6, SysML-1.7, SysMLv2, SysPhS-1.1 Connector SysPhS, SysML, Systems Modeling Language
ANTI-PATTERN, ISSUE 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 Connector ItemFlow SysPhS, SysML, antipattern
CONVENTION, MODELLING, NAMING 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). SysML-1.6, SysML-1.7, SysPhS-1.1 Unit, Unit::symbol, ValueType, ValueType::unit Modelica, SysPhS, humidifier, scientific unit system, SI unit, SI alternative unit, litre
CONVENTION, MODELLING, NAMING 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"). SysML-1.6, SysML-1.7, SysPhS-1.1 Unit, Unit::symbol, ValueType, ValueType::unit Modelica, SysPhS, humidifier, scientific unit system, SI unit, SI alternative unit
ISSUE 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. SysML-1.6, SysML-1.7, SysPhS-1.1 Unit, Unit::symbol, ValueType, ValueType::unit Modelica, humidifier, SysPhS, temperature, celsius
ASSERTION 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! SysPhS, vapour, steam, gas
ASSERTION 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). SysPhS, humidifier
ASSERTION 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). SysPhS-1.1 constraint parameter, ConstraintBlock SysPhS, dimensional analysis
ASSERTION 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. SysPhS, humidifier
ASSERTION 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 Unit, ValueType, ValueType::unit SysPhS, dimensional analysis, vapour, steam, water
ASSERTION Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "radiation" is a rate (equivalent to a power). SysPhS
ASSERTION Webel vs SysPhS-1.1: Annex A.5: Humidifier: It is assumed that "energy" is a rate (equivalent to a power). SysPhS
ASSERTION 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 SysPhS-1.1 constraint parameter, ConstraintBlock SysPhS, dimensional analysis
ASSERTION 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. SysPhS, volumetric heat capacity, specific heat capacity, water, steam, vapour
ASSERTION 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" SysPhS-1.1 constraint parameter, ConstraintBlock SysPhS, dimensional analysis
ISSUE 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. SysPhS-1.1 constraint parameter, ConstraintBlock SysPhS, dimensional analysis
ISSUE 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. SysPhS-1.1 constraint parameter, ConstraintBlock SysPhS, dimensional analysis, litre, water, volume, gram, scientific unit system, units, SI unit, ISO-80000
ASSERTION 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). SysPhS, volumetric heat capacity, thermodynamics
ASSERTION 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 constraint parameter, ConstraintBlock SysPhS, dimensional analysis
ASSERTION 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. SysPhS-1.1 constraint parameter, ConstraintBlock SysPhS, dimensional analysis
ASSERTION 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' SysPhS-1.1 Property::redefinedProperty SysPhS
ASSERTION Webel vs SysPhS-1.1: Annex A.5: Assume the conversion value property name 'SaturationVaporPressure::hPa2Pa' stands for 'hectopascal to pascal'. SysPhS-1.1 Property::redefinedProperty SysPhS
ISSUE Webel vs SysML-1.6: There is no «port» stereotype keyword for Port or Property in UML-2.5.1 or SysML-1.6, it is introduced as a custom (user-defined) stereotype keyword here only to mimic the spec Figure 9-8. SysML-1.6 «keyword», Port SysML specification figure
FEATURE, TIP, TOOL Webel vs Mathematica: The Very Good, The Bad, and The Ugly Mathematica, Wolfram, Wolfram Language, Mathematica:Dataset
CONVENTION, TIP Webel use editorial Sterotypes prefixed with ! and ? in and in CAPS in keywords such as: «!». «?», «!ERROR», «!ISSUE», «!CAUTION», «!WARNING», «!CAVEAT», etc. Stereotype Webel Best Practice
POLICY Webel Twin Pattern: The sensor/actuator twinning control loop can involve automated devices (SensorDevice and/or ActuatorDevice) and or humans (SensorHuman and/or ActuatorHuman). Webel Twin Pattern, control system, actuator, sensor
POLICY Webel Twin Pattern: The primary aim of the digitalEntity:@Entity of a DigitalTwin is to replicate its physical:PhysicalEntity as closely as possible (not to explore variants). SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, WTP:DigitalEntity, WTP:«digital»
POLICY Webel Twin Pattern: The information and data in AssetSpecification leveraged for creation of a new ActualPhysicalAsset need not necessarily only be «digital». Webel Twin Pattern, digital twin
POLICY Webel Twin Pattern: Once a PotentialPhysicalAsset has been integrated with a real, existing (has mass) ActualPhysicalAsset under twinning control, its job is done forever (although it may be kept as an historical tracking record). SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, WTP:PotentialPhysicalAsset, WTP:ActualPhysicalAsset
ASSERTION Webel Twin Pattern: Not every twinnable PhysicalEntity is worth treating as an asset. SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, digital twin, WTP:ActualPhysicalAsset, WTP:PhysicalEntity, asset
POLICY Webel Twin Pattern: It is a DigitalEntity (a.k.a. @Entity) - not the DigitalTwin that owns it - that directly «replicates» geometrical, spatial, and material aspects (only) of a single PhysicalEntity. SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, Webel Best Practice, WTP:DigitalTwin, WTP:PhysicalEntity, WTP:@Entity
CONSTRAINT, POLICY Webel Twin Pattern: DigitalTwin: The multiplicity of 'digitalEntity:@Entity' and 'physicalEntity:PhysicalEntity' MUST be [1] when the DigitalTwin is in the state Attached, the @Entity is in the state Bound, and the PhysicalEntity is in the state Exists. State, oclInState, Constraint Webel Twin Pattern, WTP:PhysicalEntity, WTP:DigitalEntity, WTP:@Entity, WTP:DigitalTwin
CONVENTION Webel Twin Pattern: Convention: [MIGHT CHANGE]: A '*' prefix in a Property name of a «digital» @Block in a DigitalTwin model indicates a mapped block property, which must be typed by a non-digital «mappable» Block, and must have the «@» keyword applied. Property, Stereotype block property Webel Best Practice, Webel Twin Pattern
POLICY Webel Twin Pattern: Communication between the ControlSystem of a DigitalTwin and its digitalEntity:@Entity is via a dedicated protocol (ReadTwin, WriteTwin) distinct from the sensor reading or actuator driving signals. Webel Twin Pattern, digital twin, control system
ASSERTION Webel Twin Pattern: An AssetSpecification may contain ANY information or data of ANY kind in ANY format about how to acquire, manifest, build, or create a physical asset. This information may be distributed across an @Entity and a PotentialPhysicalAsset. Webel Twin Pattern, WTP:ActualPhysicalAsset, WTP:AssetSpecification
POLICY Webel Twin Pattern: An ActualPhysicalAsset is an asset that is also a «physical» PhysicalEntity. Webel Twin Pattern, WTP:ActualPhysicalAsset, WTP:PhysicalEntity, digital twin
POLICY Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) is NOT a representation! It is a digital encapsulation (it can only be perceived at the level of "bits and bytes"). It HAS many representations (such as views)! SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, WTP:DigitalEntity, WTP:@Entity, SysML, Systems Modeling Language
POLICY Webel Twin Pattern: A «digital» DigitalEntity (a.k.a. @Entity) encapsulates strictly geometrical, spatial, and material aspects of a «physical» PhysicalEntity only. BY DEFINITION of this pattern it DOES NOT encapsulate processes! SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, Webel Best Practice
POLICY Webel Twin Pattern: A PotentialPhysicalAsset is «digital», not «physical». It is used to acquire (an existing) or create (build, manifest, make) an «physical» ActualPhysicalAsset, which is a special case of «physical» PhysicalEntity. SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, Webel Best Practice
POLICY Webel Twin Pattern: A LogicalProcess may only act on a PhysicalEntity via a PhysicalProcess Webel Twin Pattern, WTP:LogicalProcess, WTP:PhysicalProcess
POLICY Webel Twin Pattern: A DigitalTwin must model processes and the entities they act on separately. SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, Webel Best Practice, WTP:DigitalTwin, WTP:PhysicalEntity, WTP:@Entity
POLICY Webel Twin Pattern: A DigitalTwin may use one or more variantEntity:@Entity[0..*] to explore the impact of changes (optimisation studies, trade off studies) and then use them to drive the PhysicalEntity into a desired state (via its ControlSystem). SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, WTP:DigitalEntity, WTP:«digital»
POLICY Webel Twin Pattern: A DigitalTwin manages a control loop including a PhysicalEntity and a DigitalEntity (a.k.a. @Entity) that «replicates» it. It typically includes at least one Sensor and at least one Actuator. SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, Webel Best Practice
POLICY Webel Twin Pattern: A DigitalTwin and PhysicalEntity must both be 'attached' to Sensors and/or Actuators under management of the DigitalTwin before the twinning control loop is fully entered. Webel Twin Pattern, digital twin, sensor, actuator, control system, control loop, WTP:PhysicalEntity, WTP:DigitalTwin
ASSERTION, POLICY Webel Twin Pattern: A DigitalTwin (even a "process twin" or "finance twin"), always, without exception, BY DEFINITION HERE either directly or indirectly involves at least one existing or anticipated PhysicalEntity (even if only via another DigitalTwin)! SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, Systems Modeling Language, digital twin, WTP:PhysicalEntity, WTP:DigitalTwin
ASSERTION Webel Twin Pattern: A DigitalEntity (a.k.a. «digital» @Entity) used as a digital variant must not be directly bound to a «physical» PhysicalEntity (may not directly actuate/sense/affect) SysML-1.6, SysML-1.7, SysMLv2 Webel Twin Pattern, digital twin, control system, sensor, WTP:DigitalEntity, WTP:PhysicalEntity
NAMING, POLICY Webel suggests using a verbose 'name' for leaf (child) Requirements but NO 'text' to prevent Single Source of Truth issues and for improved callout vs relationships (but this might not always work when syncing with external requirements management tools) NamedElement::name AbstractRequirement::text, Requirement Webel Best Practice, requirements engineering
DISPLAY, ISSUE, TOOL, WARNING Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins! Pin, ObjectNode MagicDraw UML, MagicDraw SysML, Cameo Systems Modeler
DISPLAY, STYLE, TIP Webel recommends (usually) display the header of a Package, Model, ModelLibrary, or Profile in the 'tab' (rather than 'top') Package, Model, ModelLibrary, Profile MagicDraw UML, MagicDraw SysML, Cameo Systems Modeler, Webel Best Practice
TIP Webel Parsing Analysis: You may create custom stereotypes applicable to a Dependency or a uni-directional Association to represent a «predicate» much like a semantic triple (subject-predicate-object) in OWL/RDF.
TIP Webel Parsing Analysis: You do not need to map every word of every snippet to the UML/SysML model! Extract only the information required for your domain modelling task to add incremental benefit. Webel Parsing Analysis
MODELLING, NAMING, POLICY Webel Parsing Analysis: While Generalizations may be collected as elicited members of a Snippet this can quickly lead to clutter in the /member list display. SysML-1.6, SysML-1.7 Generalization ElementGroup, ElementGroup::/member Webel Parsing Analysis, parsing analysis, WPA:«pa», WPA:«snippet»
MODELLING, NAMING, POLICY Webel Parsing Analysis: While Associations may be collected as elicited members of a Snippet this can quickly lead to clutter in the /member list display. Often just collecting an end Property as member is sufficient. SysML-1.6, SysML-1.7 Generalization ElementGroup, ElementGroup::/member Webel Parsing Analysis, parsing analysis, WPA:«pa», WPA:«snippet»
MODELLING, NAMING, POLICY Webel Parsing Analysis: Where too many dashed line "anchors" from Snippets to elicited members lead to clutter they may be selectively omitted from a Parsing Analysis Diagram (PAD) once each member has been collected. SysML-1.6, SysML-1.7 Comment, Comment::annotatedElement, MD:anchor Webel Parsing Analysis, parsing analysis, WPA:«pa», WPA:PAD, WPA:«snippet»
CONVENTION, TIP Webel Parsing Analysis: typically the quoted extract text (body) of a «snippet» is a short phrase, a sentence, or a couple of short sentences (but not dozens of sentences). ElementGroup Webel Parsing Analysis, WPA:«snippet», parsing analysis
MODELLING, REQUIREMENT Webel Parsing Analysis: The symbol of a Parsing Analysis Container MUST be usable on every possible diagram type SysML-1.6, SysML-1.7, SysMLv2 Webel Parsing Analysis, WPA:«snippet», parsing analysis container, Systems Modeling Language
DISPLAY, REQUIREMENT Webel Parsing Analysis: The symbol for the relationship between a Parsing Analysis Container and elicited model elements SHOULD be a dashed line (like the anchor/handle line used with a UML Comment) SysML-1.6, SysML-1.7, SysMLv2 Comment, Comment::annotatedElement ElementGroup Webel Parsing Analysis, WPA:«snippet», parsing analysis container, Systems Modeling Language
DISPLAY, REQUIREMENT Webel Parsing Analysis: The symbol for a Parsing Analysis Container MUST be text-friendly and evocative of quoting a domain source text extract SysML-1.6, SysML-1.7, SysMLv2 Webel Parsing Analysis, WPA:«snippet», parsing analysis container, Systems Modeling Language
DISPLAY, REQUIREMENT Webel Parsing Analysis: The symbol for a Parsing Analysis Container MUST be able to OPTIONALLY display a list of names of elicited model elements (a.k.a. members) SysML-1.6, SysML-1.7, SysMLv2 ElementGroup::/member Webel Parsing Analysis, WPA:«snippet», parsing analysis container, Systems Modeling Language, parsing analysis
DISPLAY, REQUIREMENT Webel Parsing Analysis: The symbol for a Parsing Analysis Container MUST be able to indicate the unique domain source document from which its analysed text extract was quoted. SysML-1.6, SysML-1.7, SysMLv2 Webel Parsing Analysis, WPA:«snippet», parsing analysis container, Systems Modeling Language, parsing analysis
MODELLING, NAMING, POLICY Webel Parsing Analysis: The name of a Parsing Analysis Diagram (PAD) may be drawn from a focus Snippet OR may simply indicate a topic of interest to the analysis SysML-1.6, SysML-1.7 Diagram, NamedElement, NamedElement::name Webel Parsing Analysis, parsing analysis, WPA:«pa», WPA:«snippet», WPA:PAD