Dr Darren says: 'You can't obtain the optimum benefit of graphical engineering with SysML without becoming mindful of the cognitive and artistic aspects of graphical modelling. The "Zen of SysML" matters!' Just like an elegant electronics device design.
An Open Letter to LinkedIn SysML/MBSE groups from Dr Darren: "But, but, but, that SysML Diagrams doesn't show [insert pet systems engineering principle here]". It doesn't have to! It just has to show (or teach) something useful with SysML in a SysML tool!
SysML tools can ALSO be used for many graphical Model-Based Engineering tasks that benefit from Single Source Of Truth - and even without any formal System Engineering methodology (which is NOT to say that formal System Engineering is not also useful).
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!"
Webel: SysML: Heard of "follow the money"? In MBSE we "follow the flows"! Identify requests, data packets, messages, signals early on and use ItemFlow as often as you can wherever you can! Adopt a signal processing mindset throughout (systems thinking).
Webel: SysML1.7: Port contract matching is Feature-based, not Type-based. There's nothing particularly magical or special about use of an ~InterfaceBlock on a "conjugating" SysML Port, it's just a convenient way of managing one-to-one Feature matching!
Webel: SysML/MBSE: Dr Darren's Open Letter on why you may initially need the Model-Based (MB) and Single Source Of Truth aspects of MBSE more than the formal Systems Engineering (SE) aspect (or even initially no formal SE process at all) to benefit most!
Mathematica: Webel: You get compelling incremental value out of Mathematica even if you don't yet command all of the syntax and massive powers of the Wolfram Language!
Webel on Mathematica and the Wolfram Language vs Python. Python is not even close, not even vaguely close, it's not in the same league, as the Wolfram Language and Mathematica!
Psychrometrics: Calculations of the mass flow rate of the dry air component (assumed constant under steady state) from the ENTRY volumetric flow rate of the humid air mixture MUST use the INITIAL state variables!
Psychrometrics: The volumetric flow rate of a humid air mixture MAY change between a State1 and State2 (but the mass flow rate of dry air does not under steady state)! This is sometimes "glossed over" in some online calculators and less formal guides.
In the course PDF for 'CED Engineering: Air Conditioning Psychrometrics (A.Bhatia)' the term "enthalpy (h)" usually refers to the mass-specific enthalpy per dry air (in CoolProp notation 'Hda')
Webel: SysML: MagicDraw/Cameo: Strongly recommend that you set the Perspective to 'Full Featured' and 'Expert' at the very beginning at the start of every new project
Mathematica: The awesome Quantity system for values with units is everything the SysMLv1.x Quantity/Unit system should have been (and hopefully SysMLv2 will be). But it comes at a high performance cost!
"Everything now uses functional, nobody uses object-oriented anymore ... " WRONG: Grow up! Dr Darren (Webel IT)
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.]
Webel: The single biggest disease in the world of IT is the idea that somehow mathematics is bad, or not useful, or not efficient, and that getting people who don't like maths to make stuff up (badly) in coding languages (rather than using maths) is ok.
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).
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!
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 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 tool support 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)*(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.
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'
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: 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)
[HISTORICAL] 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 ARCHIVAL (2022): This content is now considered historical only!
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.)
Webel: SysMLv1: 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 [Helps prevent a clash/issue]
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/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).
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!
ALL Model-Based Engineering: Just because you can't see a Feature or some other aspect of a SysML (or UML) Element in a tool on a symbol does NOT mean it does not exist in the underlying model (repository)! The model is not just what is DISPLAYED!
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.
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
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)
SysMLv1.6 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)! [See also the SysMLv1.7 spec changes.] ARCHIVAL (2022): This content is now considered historical only!
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 SysML1.6+ 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)!
