ASSERTION

Webel Parsing Analysis: A stereotype with keyword «pa:from» may be applied to a Dependency from a Package to another Package within the Source Input Zone to indicate that all of its Elements were directly or indirectly elicited from source Documents.

Using Model-Based Systems Engineering with ANY version of Systems Modeling Language (SysML) is better than just doing drawings in a graphics tool or presentation tool

You DO NOT have to wait for SysMLv2 to do excellent Model-Based Systems Engineering with SysML! You can do MOST of what you need to do with SysMLv1.6/1.7 and you WILL be able to migrate models to SysMLv2 (once it matures). Start your SysML models NOW!

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!

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 a control loop, the 'got' (sensed) value is not in necessarily exactly the same as the actual, physical value being controlled! Typically it will be limited to a certain performance accuracy (and an intrinsic accuracy limit due to the number of bits).

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'

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 HumidityBalanceConstraint implies constraint parameter 'airExRate' in {change=((humidity-envH)(volumeairExRate))} 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.

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.

SysML: Although not encouraged, you can still use a DataType to type a Property of a Block, it just won't be listed in the 'values' compartment. Prefer the SysML ValueType versions of primitives!

SysML-16: Taken literally the text and OCL of constraint 'Block::6_valueproperties_composite' imply that every FlowProperty typed by a ValueType should have AggregationKind 'composite'

This page identifies a possible issue, inconsistency, concern, error, or bug!

One of the ways Webel IT Australia helps promote tools, technologies, and languages is by donating a lot of time identifying, tracking, and reporting potential issues, in order to help vendors and developers improve the tools and technologies. In some cases, we also offer workarounds and advice for users. All issues tracked on our public site are offered most constructively and with sincerest gratitude to the tool vendors and technology developers.

SysPhS: GOTCHA: By default PhSConstant maps to a Modelica parameter (not to a Modelica constant)

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: Not every twinnable PhysicalEntity is worth treating as an asset.

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)!

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: Some users employed the ~ tilde prefix for a conjugated Port type long before it was introduced for ~InterfaceBlock and you MAY use it to name a regular Block that is not an ~InterfaceBlock

Cameo: UML: When sending a Signal via a Port with a SendSignalAction, Cameo does not care whether the Port is conjugated (even if it should).

Cameo: SysML: When sending a Signal via a Port with a SendSignalAction, Cameo does not care what the directed feature directions of the Signal receptions on the Type of the Port are (even if it should).

The SysML InterfaceBlock can be used for general contracts (it is NOT just for use as the Type of a ProxyPort)!

In Webel Parsing Analysis elicited model elements MUST eventually be moved out of the 'source' (or '0-source') Package/Model zone and under a main project Package/Model area. (Use the owner display option to check.)

MagicDraw/Cameo: AVOID the "default" SysML Item Flow Creation Mode 'Between Part Types' completely. Use 'Direct' mode, change it as soon as you start any SysML project under Options → Project → General → SysML.

MagicDraw/Cameo: On EVERY project of ANY kind set the Environment Perspective to Full-Featured and check the Expert box, even if you are a "novice".

Cameo/MagicDraw: The Classifier specification setting 'isAbstract' is (for reasons that beggar belief or engineering reason) not by default visible in the Element specification dialog. Enable expertise level 'All' (and for always everwhere).

MagicDraw/Cameo: Set EVERY element properties and 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 dialog search filters!

Just because you can't see a Feature or some other aspect of a UML or SysML Element in a tool on a symbol does NOT mean it does not exist in the underlying model (repository)!

Rule #1: A UML or SysML Element in a tool is NOT just an Element symbol in a diagram! A Note is not an Element (compare with a Comment).

The entry, doActivity, and effect Behaviors defined on a submachine State are specific that particular usage of its Submachine

Visual nesting of InstanceSpecification symbols has no meaning in the underlying model, only assignment to a Slot does!

When dealing with required Interfaces you must use Usage (not Dependency) and it has dedicated "socket" notation.

When domain modelling with SysML, Generalization, inheritance, and even multiple inheritance are not "evil" and can be used relatively freely. We are not doing code-oriented Decorator patterns - an implementation choice - we are doing domain modelling!

If an abstract Block or Class in a domain model has Associations to Blocks or Classes that are not also abstract, it's often a hint that you have not identified a correct abstraction layer.

SysML Blocks have lots of possible features and compartments, lots of capabilities, and are very powerful! But you don't have to use every aspect of a Block (or show every aspect in every diagram) at once on every project.

MagicDraw/Cameo support for the SysML Parametric Diagram and ConstraintBlocks for equations and mathematics is excellent, and it integrates with powerful maths engines such as Mathematica. It CAN be used on industrial strength real-world projects.

The SysML Parametric Diagram and the ContraintBlock technology for equations and mathematics is clever, powerful, useful, and integrates well with the other model-based engineering aspects of SysML.

Webel Parsing Analysis (with strict traceability of all elicited model elements) can be used side-by-side with "freestyle" modelling with incremental benefit the more it is used.

The Webel Parsing Analysis recipe promotes a clearly scoped modelling workflow.

Even relatively informal elicitation of model elements using the SysML ElementGroup and a Parsing Analysis approach is extremely powerful.

Translating authoritative technical documents written in “natural” engineering language (snippet-by-snippet) into Webel Parsing Analysis diagrams creates consistent underlying systems models and can bridge easily to existing methodologies.

Humans work well with natural language: Many stakeholders – including those who are not necessarily familiar with UML or SysML modelling symbols and diagrams - benefit enormously from having plain text in diagrams side-by-side with graphics.

Webel Parsing Analysis is a "meta-process" that can be applied to general domain source documents to elicit Requirements (and related model elements) or to a Requirements Specification itself as a special case of a domain source document!

Not even the most experienced requirements engineers can easily state requirements perfectly in consistent requirements-friendly language first shot; requirements and constraints are often buried in the natural text of domain source documents.

Webel Parsing Analysis: If you wish to show a «snippet» comment symbol (with its body text) in a presentation diagram (that is NOT a «pa» diagram) remove the '/member' tagged value from display so the only visible tagged value is 'source'.

The UML Artifact and its UML standard profile extensions such as «document» Document and «file» File are NOT included in UML4SysML.

The «Subsystem» stereotype for UML Components has nothing to do with the non-normative SysML «subsystem» stereotype for Blocks

The SysML non-normative extended requirements are NOT offered as the ultimate set of requirements categories or requirements fields, but they are highly usable and can be easily adapted.

The OMG SysML language deliberately does not aim to restrict users and tools to one strict systems engineering methodology; it provides flexible capabilities and options for use by many model-based systems engineering methodologies and tools.

A FlowProperty need not have 'composite' AggregationKind, it can be 'shared' or 'none'. (The MagicDraw/Cameo default is 'none').

SysML directional FlowProperty contracts for ProxyPorts SHOULD be satisfiable Property-wise (including as subsets of Properties) not necessarily just at the level of entire Blocks!

Typing a "standard" Port by an InterfaceBlock or ~InterfaceBlock IS allowed AND can be useful; typing a FullPort by an InterfaceBlock or ~InterfaceBlock is formally allowed but not so useful, because it would have no parts or behaviors to do anything.

You can't make connections in BDDs, only in IBDs. A BDD shows where connections may be made, an IBD shows where specific connections have been made in a specific context!

SysML-1.6: Needs a constraint on ~InterfaceBlock making the implied inversion of provided/required Interfaces explicit

This page identifies a possible issue, inconsistency, concern, error, or bug!

One of the ways Webel IT Australia helps promote tools, technologies, and languages is by donating a lot of time identifying, tracking, and reporting potential issues, in order to help vendors and developers improve the tools and technologies. In some cases, we also offer workarounds and advice for users. All issues tracked on our public site are offered most constructively and with sincerest gratitude to the tool vendors and technology developers.

The SysML block compartment name 'initialValues' for what are really "context-specific values" is confusing - even completely misleading; please just think of them as 'contextValues' (and initial values as a special context case)

SysML provided/required DirectedFeature contracts for ProxyPorts SHOULD be satisfiable Feature-wise (including as subsets of Features) not necessarily just at the level of entire Blocks (types)!

SysML: Typing a Port by an InterfaceBlock or ~InterfaceBlock does NOT imply that the Port is a ProxyPort (but ProxyPort must be typed by an InterfaceBlock or ~InterfaceBlock)

SysML: The «system», «subsystem», «external», «domain» and «system context» keywords are for "user defined" block Stereotypes (they are not part of core SysML); they are supported in MagicDraw/Cameo as Non-Normative Extensions.

The SysML specification refers to 'part property' as a concept (as a type of block property) but there is no stereotype PartProperty; MagicDraw/Cameo as an additional stereotype PartProperty to encapsulate the concept

Visual containment of the symbol for a UseCase in the rectangular symbol for a subject Classifier does NOT imply ownership! Packaging (ownership) of UseCases is separate from use within subjects, and a single UseCase may be used in more than one subject.

In the Webel recipe for SysML, DO use a "standard" Port until you have a truly compelling reason to commit to a FullPort or ProxyPort

It is NOT true in SysML that you "should" always use a SysML FullPort or a SysML ProxyPort instead of a "standard" Port, and it's not even always a good idea (and the spec states this very clearly in multiple places)!

Subscribe to ASSERTION