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
DISPLAY, MODELLING, TIP, TOOL SysML/UML: MagicDraw/Cameo: To display the body of an OpaqueBehavior on a usage (CallBehaviorAction) in an Activity Diagram use an element property callout of 'Body' into a Note with a handle to the CallBehaviorAction SysML-1.6, SysML-1.7, UML-2.5.1 CallBehaviorAction, OpaqueBehavior, Activity Diagram, Note, callout SysML Activity Diagram Systems Modeling Language, Unified Modeling Language, SysML, MagicDraw SysML, Cameo Systems Modeler, CATIA Magic, SysMLv1.x
MODELLING, TIP, TOOL SysML1.x: MagicDraw/Cameo: The block property concept is implemented using a vendor-specific stereotype extension BlockProperty SysML-1.6, SysML-1.7 block property, MD:BlockProperty MagicDraw SysML, Cameo Systems Modeler, Systems Modeling Language, CATIA Magic, SysMLv1.x
MODELLING, TIP, TOOL SysML1.x: MagicDraw/Cameo: The constraint parameter concept is implemented using a vendor-specific stereotype extension ConstraintParameter SysML-1.6, SysML-1.7 constraint property, MD:ConstraintParameter MagicDraw SysML, Cameo Systems Modeler, Systems Modeling Language, CATIA Magic, SysMLv1.x
MODELLING, TIP, TOOL SysML1.x: MagicDraw/Cameo: The constraint property concept is (was) implemented using a vendor-specific stereotype extension ConstraintProperty [VENDOR-DEPRECATED] SysML-1.6, SysML-1.7 constraint property, MD:ConstraintProperty MagicDraw SysML, Cameo Systems Modeler, Systems Modeling Language, CATIA Magic, SysMLv1.x
MODELLING, TIP, TOOL SysML1.x: MagicDraw/Cameo: The nested property path concept is implemented using a vendor-specific stereotype extension NestedPropertyPath SysML-1.6, SysML-1.7 nested property path, MD:NestedPropertyPath MagicDraw SysML, Cameo Systems Modeler, Systems Modeling Language, CATIA Magic, SysMLv1.x
MODELLING, TIP, TOOL SysML1.x: MagicDraw/Cameo: The part property concept is implemented using a vendor-specific stereotype extension PartProperty SysML-1.6, SysML-1.7 part property, MD:PartProperty MagicDraw SysML, Cameo Systems Modeler, Systems Modeling Language, CATIA Magic, SysMLv1.x
MODELLING, TIP, TOOL SysML1.x: MagicDraw/Cameo: The reference property concept is implemented using a vendor-specific stereotype extension ReferenceProperty SysML-1.6, SysML-1.7 reference property, MD:ReferenceProperty MagicDraw SysML, Cameo Systems Modeler, Systems Modeling Language, CATIA Magic, SysMLv1.x
MODELLING, TIP, TOOL SysML1.x: MagicDraw/Cameo: The shared property concept is implemented using a vendor-specific stereotype extension SharedProperty SysML-1.6, SysML-1.7 shared property, MD:SharedProperty MagicDraw SysML, Cameo Systems Modeler, Systems Modeling Language, CATIA Magic, SysMLv1.x
MODELLING, TIP, TOOL SysML1.x: MagicDraw/Cameo: The value property concept is implemented using a vendor-specific stereotype extension ValueProperty SysML-1.6, SysML-1.7 value property, MD:ValueProperty MagicDraw SysML, Cameo Systems Modeler, Systems Modeling Language, CATIA Magic, SysMLv1.x
ASSERTION, OPTION 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-1.6, SysML-1.7 DataType, properties compartment, attributes compartment ValueType, values compartment SysML, Systems Modeling Language
CAVEAT, GOTCHA, LIMITATION, MODELLING, TIP SysML: Cameo Systems Modeler: A ValueType that does not extend Real might not always simulate correctly when used to type a constraint parameter of a ConstraintBlock (in a SysML Parametric Diagram) or to type a parameter (in a SysML Activity Diagram)! Parameter, Activity, Action, Pin ConstraintBlock, constraint parameter, SysML Parametric Diagram, SysML Activity Diagram, Real, ValueType, value property Cameo Systems Modeler, Magic Model Analyst [Cameo Simulation Toolkit], MagicDraw SysML, SysML, CATIA Magic, Systems Modeling Language, simulation, execution
CAVEAT, MODELLING, TOOL SysML: Cameo/MagicDraw: ItemFlow notation/indication on ObjectFlow edges in SysML Activity Diagrams is a tool-specific feature, although it was proposed and discussed (but DEFERRED) as part of the OMG SysMLv1 Revision Task Force (RTF). SysML Activity Diagram, ItemFlow SysML, MagicDraw SysML, Cameo Systems Modeler, CATIA Magic
MODELLING, TIP SysML: Electronics: When modelling electronics systems you should to decide and make clear (with ItemFlow and/or Stereotypes) whether you are modelling signals (information, does not care about GND) or a physical design with voltage (needs GND) Signal, InformationFlow, Stereotype, custom Stereotype ItemFlow electronics, Systems Modeling Language, wiring, GND, signal flow, signal processing
MODELLING, PATTERN, TIP SysML: Electronics: When modelling ground (GND) use a Port type that has an inout FlowProperty Port FullPort, ProxyPort, FlowProperty, FlowProperty::direction, FlowDirectionKind::inout, InterfaceBlock, ~InterfaceBlock electronics, Systems Modeling Language, port-based engineering, SysML
MODELLING, OPTION, TIP SysML: Flows: If you intend to use a Classifier to type the itemProperty of an ItemFlow on a Connector use a ValueType or Block rather than a Signal, otherwise you'll get probably-unwanted signal receptions on the owning context Block. SysML-1.6, SysML-1.7 Signal, InformationFlow, InformationFlow::conveyed Block, ValueType, ItemFlow, ItemFlow::itemProperty Systems Modeling Language, SysML, flow, signal flow, Webel Best Practice
ANTI-PATTERN, CAVEAT, MODELLING SysML: Having a Behavior owned by a Block it is allocated to may undermine purist functional allocation (because it presupposes the element of the physical solution that carries out the function) SysML-1.6, SysML-1.7 Element::owner, BehavioredClassifier::ownedBehavior, BehavioredClassifier::classifierBehavior, Behavior, Activity Allocate, Block functional allocation, SysML, Systems Modeling Language, systems engineering
MODELLING, TIP SysML: HOWTO Represent a person as an external block-based SysML «actor» in one lower context and as an internal participating «person» in another higher context, with traceability. For modelling systems of systems in a team with many modellers. SysML-1.6, SysML-1.7 «keyword», custom Stereotype, Stereotype SysML, Systems Modeling Language, SysMLv1, MBSE, Model-Based Systems Engineering, Cameo Systems Modeler, MagicDraw SysML, CATIA Magic, Webel Best Practice
PATTERN SysML: HOWTO Safely incorporate ConstraintBlock equations from a library into a project with local ValueType variants: CASE: SysPhS vs ISO-80000 ModelLibrary SysML-1.6, SysML-1.7, SysPhS-1.1 ConstraintBlock, constraint parameter, ValueType, value property, Unit, ValueType::unit Systems Modeling Language, Cameo Systems Modeler, SysML, MD SysML, MagicDraw SysML, ISO-80000, SysPhS
PATTERN SysML: HOWTO Use an explicit converter between different Unit systems SysML-1.6, SysML-1.7, SysPhS-1.1 ConstraintBlock, constraint parameter, ValueType, value property, Unit, ValueType::unit Systems Modeling Language, Cameo Systems Modeler, SysML, MD SysML, MagicDraw SysML, ISO-80000, SysPhS
FEATURE, TOOL SysML: MagicDraw/Cameo can optionally indicate Requirement IDs in tables Requirement, AbstractRequirement::id requirements engineering, table, query table, report table, MagicDraw SysML, Cameo Systems Modeler
DISPLAY, POLICY, SETTINGS, STYLE, TOOL SysML: MagicDraw/Cameo: Diagram Style: Recommend DO NOT use shadows or gradient fill adornments on diagrams! [TIP OFTEN IGNORED] SysML-1.6, SysML-1.7, SysMLv2, UML-2.5.1 SysML, Systems Modeling Language, Webel Best Practice, Cameo Systems Modeler, MagicDraw SysML
DEPRECATION, TOOL, WARNING SysML: MagicDraw/Cameo: DO NOT use the FlowPort or FlowSpecification menu items or smart manipulator items they are completely OBSOLETE (they create fully DEPRECATED SysML model element types)! Use FlowProperty on Block features instead. SysML-1.6 DEPRECATED:FlowPort, DEPRECATED:FlowSpecification Cameo Systems Modeler, MagicDraw SysML, CATIA Magic:v2022xGolden, CATIA Magic:v2024xGolden
MODELLING, TIP, TOOL SysML: MagicDraw/Cameo: Use query view tables, matrices, and maps, use them a lot! They help communicate well with other stakeholders. Learn how to use the Generic Table diagram type, custom relations, Simple Navigation & Metachain Navigation (expert)! SysML, Systems Modeling Language, SysMLv1, MBSE, Model-Based Systems Engineering, Cameo Systems Modeler, MagicDraw SysML, CATIA Magic, Webel Best Practice, table, query, model query, table query, query matrix, dependency matrix, matrix, relationship map, relationship matrix, derived relationships, MagicDraw implied relationships
NAMING, POLICY SysML: Naming: Always use either anonymous or first letter lower case for Property, ObjectNode and InstanceSpecification names; no exceptions (unless using names to "quote text")! Valid: 'lowerCamelCase' OR 'tla' vs TLA acronym OR 'uCC' vs UpperCamelCase Property, StructuralFeature, InstanceSpecification, ObjectNode, NamedElement::name MD:ValueProperty UML, SysML
ANTI-PATTERN, CAVEAT, MODELLING, NAMING, WARNING SysML: Naming: Including Block, ValueType, and Signal names in the names of Behaviors (such as Activities) can sometimes undermine purist functional allocation (because it may presuppose the element of the physical solution that carries out the function). SysML-1.6, SysML-1.7 Element::owner, BehavioredClassifier::ownedBehavior, BehavioredClassifier::classifierBehavior, Behavior, Activity, Signal Allocate, Block functional allocation, SysML, Systems Modeling Language, systems engineering
ANTI-PATTERN, CAVEAT, MODELLING, NAMING, WARNING SysML: Naming: You may include Block, ValueType, and Signal names in the names of Behaviors (such as Activities) as long as this does not undermine the principles of functional analysis and allocation. SysML-1.6, SysML-1.7 Element::owner, BehavioredClassifier::ownedBehavior, BehavioredClassifier::classifierBehavior, Behavior, Activity, Signal Allocate, Block functional allocation, SysML, Systems Modeling Language, systems engineering, functional analysis, Webel Best Practice
NAMING, STYLE SysML: Non-anonymous (concise please) block property names and port names may help a little in tracing participation of properties and ports in requirements relationships and play nicely with current SysML callout style. Short role indicators are best! NamedElement::name block property, value property, part property, AbstractRequirement::/satisfiedBy, AbstractRequirement::/tracedTo, Satisfy, Trace
ANTI-PATTERN, MODELLING SysML: Syntax ain't Semantics: FUN CHALLENGE: SysMLv1 block property aggregation: 'The tornado chaser plane "has" a chaser car "with" a chaser team.' AggregationKind, AggregationKind::composite, AggregationKind::shared, Property, Property::aggregation Block, SysML Block Definition Diagram, part property, reference property, shared property, MD:SharedProperty SysML, Systems Modeling Language, SysMLv1, MBSE, Model-Based Systems Engineering, Webel Best Practice, syntax, semantics
GOTCHA, MODELLING, WARNING SysML: The placement of usages of Blocks, their Ports, and Connectors in an Internal Block Diagrams DOES NOT necessarily represent physical geometry! SysML-1.6, SysML-1.7, SysMLv2, UML-2.5.1 Connector, Port SysML Internal Block Diagram, Block, "standard" Port SysML, Systems Modeling Language
ASSERTION, TOOL 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. SysML-1.6 «system», «subsystem», «external», «domain», «system context» non-normative, MagicDraw SysML, Cameo Systems Modeler
ASSERTION 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-1.6 Type, TypedElement, TypedElement::type InterfaceBlock, ~InterfaceBlock, ProxyPort, "standard" Port, FullPort
COMPLICATION, TOOL, WARNING SysML: Using redefined Property and Property::defaultValue to create deep hierarchical value configurations of "initial values" configurations for SysPhS simulation is notoriously fiddly and requires experience and patience. Better tool support is needed! Property::defaultValue, Property::redefinedProperty SysML, Systems Modeling Language, MagicDraw SysML, MD SysML, Cameo Systems Modeler, system configuration, deep configuration, modes, SysPhS
TIP SysML: Webel recommends use of an additional custom «requirementGroup» stereotype for compound Requirements that serve as owning Namespaces and are subject to the satisfaction policy that all child requirements must be satisfied. Stereotype, «keyword» Requirement, composite (compound) requirement
NAMING, POLICY, STYLE SysML: Webel: "Trust the Type!" - Often the name of the Type of an anonymous Property or instance-level element is completely sufficient to indicate its role - unless multiple Properties of the same Type have different roles within the same owner context! NamedElement::name, Property, InstanceSpecification, Port Webel Best Practice
MODELLING, PATTERN, TIP SysML: When using Property::defaultValue and Property::redefinedValue to carry a "shadow hierarchy" of redefinitions across an entire system hierarchy, considering using a user-defined keyword such as «configuration» or «scenario» on each redefining Block SysML-1.6, SysML-1.7, UML-2.5.1 Property::redefinedProperty, Property::defaultValue, Stereotype, «keyword», user defined Stereotype, custom Stereotype MD SysML, Systems Modeling Language, UML, MagicDraw UML, MagicDraw SysML, Webel Best Practice
MODELLING, OPTION, TIP SysML: Whether you use a Block, ValueType, or Signal to represent something that flows (and can be applied to an ItemFlow) depends on what you want to achieve. If you want to indicate something structured with value properties with Units use a Block. SysML-1.6, SysML-1.7 Signal, InformationFlow, InformationFlow::conveyed Block, ValueType, ItemFlow, ItemFlow::itemProperty Systems Modeling Language, SysML, flow, signal flow, Webel Best Practice
MODELLING SysMLv1 (or v2): CHALLENGE EXERCISE: Simplified Parsing Analysis breakdown of 'Build an Airport' with variations ElementGroup, ElementGroup::/member, AbstractRequirement, Satisfy, Refine, DeriveReqt Webel Parsing Analysis, Systems Modeling Language, requirements engineering, WPA:«snippet», WPA:Snippet::source, Model-Based Systems Engineering, MBSE, SysML
ASSERTION, WISHLIST 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.] SysML-1.6 Feature, BehavioralFeature, Reception, Operation, StructuralFeature, Property provided Feature, required Feature
CAVEAT, COMPLICATION, LIMITATION SysMLv1.x: Limitation: The 'body' (maths formula) of an OpaqueBehavior can't be synchronised (shared) with the 'constraint' of a ConstraintBlock (directly in the SysML model). Can lead to a WET (not DRY) model and breaks Single Source of Truth! Constraint, OpaqueBehavior:body, OpaqueBehavior:language, Activity, OpaqueBehavior, Abstraction ConstraintBlock, SysML Parametric Diagram, SysML Activity Diagram DRY, WET, Single Source of Truth, Systems Modeling Language, SysMLv1.x, Model-Based Systems Engineering, Wolfram, Mathematica
CAPABILITY, FEATURE, TIP, TOOL SysMLv1.x: MagicDraw/Cameo: Contextual relationships feature (links) contextual relationship, Allocate, Satisfy, Refine, Trace, Verify Systems Modeling Language, Cameo Systems Modeler, MagicDraw SysML, MD SysML, Magic, CATIA Magic:v2021xR1, CATIA Magic, CATIA Magic:v2021x
QUESTION SysMLv1.x: Q: Why can't a Package with PackageImports be used as a Parsing Analysis text container? Why is the SysML1.6 ElementGroup (extended and customised as the Webel «snippet») far better suited for text-driven model element elicitation? SysML-1.6, SysML-1.7, UML-2.5.1 Comment::annotatedElement ElementGroup, ElementGroup::/member WPA:«snippet», WPA:«pa»
NAMING, POLICY SysMLv1.x: ValueType naming: The Webel convention is 'UpperCamelCase' (a.k.a. PascalCase). ValueType, QuantityKind Webel Best Practice
MODELLING SysMLv1: "Should" the 'subject' of a top-level UseCase be a System or (a particular) SystemContext? Answer: Which one would you like to be correct!? [WITH EXTERNAL LINKS] SysML-1.6, SysML-1.7 UseCase, UseCase::subject SysML Use Case Diagram, System, SystemContext Model-Based Systems Engineering, SysML, Systems Modeling Language, SysMLv1
MODELLING SysMLv1: A common misunderstanding: Just because a UseCase symbol appears inside the rectangle of a subject Classifier does NOT mean that it is owned by that Classifier and can only have that one Classifier as 'subject', and it does not imply ownership! SysML-1.6, SysML-1.7 UseCase, UseCase::subject SysML Use Case Diagram, System, SystemContext Model-Based Systems Engineering, SysML, Systems Modeling Language, SysMLv1
MODELLING, TIP SysMLv1: A part Property or reference Property is not necessarily a 'memberEnd' or 'ownedEnd' of an Association ('association' or 'owningAssociation'). But an Association always as at least 2 'memberEnd' Properties. (With some MagicDraw/Cameo tool tips.) SysML-1.6, SysML-1.7 Association, Association::memberEnd, Property::owningAssociation, Association::ownedEnd, Property::association part property, MD:PartProperty, reference property, MD:ReferenceProperty Model-Based Systems Engineering, SysML, Systems Modeling Language, SysMLv1, MBSE
MODELLING, NAMING, TIP SysMLv1: An ItemFlow without an assigned 'itemProperty' is sometimes informally/casually referred to as an "information flow", especially when applied to an Association (because it is much like a UML InformationFlow), but formally it is a SysML ItemFlow. InformationFlow, InformationFlow::conveyed, InformationItem ItemFlow, ItemFlow::itemProperty
GOTCHA, TIP SysMLv1: Cameo Simulation Toolkit: 2024x: GOTCHA: SendSignalAction: Nested Ports won't appear in the selection dialog for 'onPort' (or work for Drag n' Drop) unless «InvocationOnNestedPortAction» has been applied (they are filtered out). SysML-1.6, SysML-1.7 InvocationAction::onPort, SendSignalAction InvocationOnNestedPortAction, InvocationOnNestedPortAction::onNestedPort SysML, Systems Modeling Language, SysMLv1, MBSE, Model-Based Systems Engineering, Cameo Systems Modeler, MagicDraw SysML, CATIA Magic, Magic Model Analyst [Cameo Simulation Toolkit]
MODELLING, OPTION, TIP SysMLv1: MagicDraw/Cameo: Automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties of a Block. EXAMPLE: A UseCase scenario within a SystemContext as UseCase ‘subject’. SysML-1.6, SysML-1.7 UseCase, Use Case scenario, Actor, UseCase::subject SysML Activity Diagram, swimlane, custom block-based «actor», part property Systems Modeling Language, SysML, MD SysML, Model-Based Systems Engineering, scenario
CONVENTION, FEATURE, MODELLING, OPTION, TIP, TOOL SysMLv1: MagicDraw/Cameo: Having a SystemContext as the 'subject' of each main UseCase plays nicely with the feature for automated creation of usage-level allocation swimlanes in SysML Activity Diagrams for part properties. But it's not the only way. SysML-1.6, SysML-1.7 UseCase, Use Case scenario, Actor, UseCase::subject SysML Activity Diagram, swimlane, custom block-based «actor», part property, SystemContext Systems Modeling Language, SysML, MD SysML, Model-Based Systems Engineering, scenario, MagicGrid, MagicDraw SysML, Cameo Systems Modeler, CATIA Magic, primary scenario
MODELLING, TIP, TOOL SysMLv1: MagicDraw/Cameo: HOWTO show "missing" ItemFlows after using Display Related Elements to re-draw Associations and Connectors. Use the 'Show Realised Item Flows' and 'Realize All Item Flows' smart manipulators. InformationFlow::conveyed, InformationFlow, Association, Connector, InformationFlow::realizingConnector, InformationFlow::realization ItemFlow SysML, Systems Modeling Language, SysMLv1, MBSE, Model-Based Systems Engineering, Cameo Systems Modeler, MagicDraw SysML, CATIA Magic
DISPLAY, ISSUE, TOOL SysMLv1: MagicDraw/Cameo: If redisplay of an Association with an InformationFlow or ItemFlow creates a strange extra dashed line with «ItemFlow» keywords (separate from the Association) just remove (only) that extra dashed line from the diagram. InformationFlow, InformationFlow::conveyed, InformationFlow::realization ItemFlow, SysML Block Definition Diagram Cameo Systems Modeler, MagicDraw UML, MagicDraw SysML
GOTCHA, MODELLING, OPTION, TIP, WARNING SysMLv1: MagicDraw/Cameo: INTRINSIC GOTCHA: Care must be taken with ownership of Activities used as UseCase scenarios vs the ‘subject’ of the UseCase. Make sure you don’t get an Activity ‘context’ mismatch! It's up to you to manage it as intended. SysML-1.6, SysML-1.7 UseCase, Use Case scenario, UseCase::subject SysML Use Case Diagram, Block Systems Modeling Language, SysML, MD SysML, Model-Based Systems Engineering, scenario
MODELLING, TIP SysMLv1: MagicDraw/Cameo: Oh no, I lost my part or reference property? Where did it go? The Symbol Properties option for 'Show Association ends as Attributes' may help you find it! SysML-1.6, SysML-1.7 Association, Association::memberEnd, Property::owningAssociation, Association::ownedEnd part property, MD:PartProperty, reference property, MD:ReferenceProperty Model-Based Systems Engineering, SysML, Systems Modeling Language, SysMLv1, MBSE, MagicDraw SysML, MD SysML, Cameo Systems Modeler, CATIA Magic
MODELLING, TIP, TOOL SysMLv1: MagicDraw/Cameo: Synchronising ItemFlows on Connectors with ObjectFlows in Activities using the Item Flow Manager. Nice! SysML-1.6, SysML-1.7 InformationFlow::conveyed, UseCase::subject, Use Case scenario, Activity, Connector, InformationFlow::realizingConnector, InformationFlow::realizingMessage, InformationFlow::realizingActivityEdge ItemFlow, SysML Block Definition Diagram, SystemContext SysML, MD SysML, Systems Modeling Language, SysMLv1, MagicDraw SysML, Cameo Systems Modeler, CATIA Magic
MODELLING, STYLE SysMLv1: Prefer not show Port symbols on the boundary of Block symbols in BDDs, just list them in compartments. One can't connect them in a BDD anyway. Recommend only show Port symbols in IBDs. SysML-1.6, SysML-1.7 Port SysML Block Definition Diagram Webel Best Practice, SysMLv1, Systems Modeling Language, SysML
MODELLING, PROPOSAL, TIP SysMLv1: TIP: You can strengthen the ill-defined semantics of Property 'aggregation' (an AggregationKind) by applying custom Stereotypes to a Property, documented with its intended use. Not perfect, but better than not. EXAMPLE: «assembled» AggregationKind, AggregationKind::composite, AggregationKind::shared, AggregationKind::none, Property::aggregation, Stereotype, custom Stereotype, «keyword» SysML, Systems Modeling Language, SysMLv1, MBSE, Model-Based Systems Engineering, Webel Best Practice
CONVENTION, MODELLING, OPTION, TIP SysMLv1: UseCase scenario representations: On use of Activity Diagrams with swimlanes and/or Sequence Diagrams (Interactions): Actor or block-based custom «actor» on 1st (typically left) Lifeline/Swimlane, System/Subsystem on 2nd Lifeline/Swimlane SysML-1.6, SysML-1.7 UseCase, Use Case scenario, Actor SysML Activity Diagram, Refine, Trace, SysML Use Case Diagram, SysML Sequence Diagram, custom block-based «actor», Allocate, ActivityAllocatePartition, swimlane Systems Modeling Language, SysML, MD SysML, Model-Based Systems Engineering, scenario
CAVEAT SysMLv1: When using model queries (such as tables) for compliance with some older systems engineering docs you may not always be able to use anonymous Property names and anonymous instance level element names. Or try the owner context or the ID! Webel Best Practice, model query, table query, report generation, report extraction
SysMLv2 will have a completely new way of dealing with instances. SysMLv2 instance, InstanceSpecification SysMLv2 SysML, Systems Modeling Language
MODELLING SysMLv2: On the v2 Comment extension of the v2 AnnotatingElement as a candidate Parsing Analysis Container SysML-1.6, SysML-1.7, UML-2.5.1 WPA:«snippet», WPA:«pa»
ISSUE, LIMITATION, WARNING 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! SysPhS-1.1 Property::redefinedProperty ValueType SysPhS, Modelica
ISSUE, TOOL SysPhS-1.1 (and MDSysML/Cameo 19SP3 SysPhSLibrary): Use of RealSignalInElement for Real.Routing.Switch::u2 inconsistent with BooleanInput of control port Modelica.Blocks.Logical.Switch::u2 SysPhS-1.1 SysPhS, MagicDraw SysML, Cameo Systems Modeler, Modelica
ISSUE SysPhS-1.1 spec version of 'Figure 38: Internal structure of the circuit example' shows some bi-directional ItemFlows for Charge on overlapping Connector line sections, which are impossible to interpret. SysPhS-1.1 Connector SysPhS
ISSUE 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. SysPhS-1.1 Connector SysPhS
TIP SysPhS-1.1 vs Modelica: On export the SysPhS signal flow Port types are flattened to remove the FlowProperty (rSig, iSig, or bSig). In the exported Modelica code you'll only ever see the Port names. Port "standard" Port SysPhS, Modelica
ISSUE 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 StateMachine SysPhS
ISSUE SysPhS-1.1: 10.12.2 SysML modeling: p.47: Name of StateMachine in 'Figure 29: State machine in SysML' should be ComputerSM (not Computer) for consistency with the Modelica code example SysPhS-1.1 StateMachine SysPhS
ISSUE 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 Property::redefinedProperty SysPhS
ISSUE 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 SysPhS
ISSUE 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 SysPhS
ISSUE SysPhS-1.1: Annex A.5: Humidifier: Naming not very consistent across parts, input/output Port name, value properties, or constraint parameters SysPhS-1.1 Port "standard" Port, Block, block property, constraint parameter, value property SysPhS
ISSUE, MODELLING 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) SysML-1.6, SysML-1.7, SysPhS-1.1 Port::isConjugated ~InterfaceBlock SysPhS
ISSUE 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 Property::redefinedProperty SysPhS
ISSUE SysPhS-1.1: Annex A.5: redefinition 'humidifierSystem {redefines humidifierSystem}' incorrect in Figure 96: Humidifier System Scenario Initial Values SysPhS-1.1 Property::redefinedProperty SysPhS
ISSUE 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. SysPhS-1.1 Constraint constraint parameter, value property SysPhS
ISSUE 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 Property::redefinedProperty SysPhS
ISSUE, MODELLING, STYLE SysPhS-1.1: Apparent use of part Property with «port» keyword (instead of standard SysML Port) leads to property path symbols appearing inside the boundary of context blocks (instead of within a Port symbol on the boundary) in IBDs and Parametric Diagrams SysPhS-1.1 «keyword», Port, Stereotype "standard" Port, block property, part property, SysML Internal Block Diagram, multi-level property path, pathname dot notation SysPhS
ISSUE, LIMITATION SysPhS-1.1: Does not support Modelica's 'experiment' annotations SysPhS-1.1 SysPhS, Modelica
ISSUE, LIMITATION, WORKAROUND 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. SysPhS-1.1 Property::defaultValue SysPhS, Modelica
ISSUE, LIMITATION SysPhS-1.1: Does not support Modelica's 'min' or 'max' on type declarations SysPhS-1.1 ValueType SysPhS, Modelica
ISSUE, LIMITATION SysPhS-1.1: Does not support Modelica's conditional declaration form. SysPhS-1.1 Modelica, SysPhS
ISSUE, LIMITATION SysPhS-1.1: Does not support Modelica's encapsulated enumeration. SysPhS-1.1 Modelica, SysPhS
COMPLICATION, TOOL, WARNING SysPhS-1.1: GOTCHA: The term "initial values" is sometimes just used to refer to the start values for a simulation run in Modelica or Simulink. It does NOT always mean the additional context-specific values mechanism of SysML beyond Property::defaultValue Property::defaultValue, Property::redefinedProperty initial values, context-specific values SysML, Systems Modeling Language, MagicDraw SysML, MD SysML, Cameo Systems Modeler, system configuration, deep configuration, modes, SysPhS
ANTI-PATTERN 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 Don't Repeat Yourself, WET, We Enjoy Typing, Single Source of Truth, SSoT
ISSUE 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). SysPhS-1.1 SysPhS, Modelica, Wolfram SystemModeler
ISSUE 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 ...'] SysPhS-1.1 SysPhS, Modelica, Wolfram SystemModeler
ISSUE SysPhS-1.1: p.30: text and Figure 22: Incorrect references to 'RealInSignalElement' and 'RealOutSignalElement' (should be RealSignalInElement, RealSignalOutElement) SysPhS-1.1 SysPhS
ISSUE 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 SysPhS, Modelica, Wolfram SystemModeler
ISSUE SysPhS-1.1: p.38: 10.9.4 Modelica modeling, signal flow: Example Modelica model should be for SpringMassSys not Spring SysPhS-1.1 SysPhS
ISSUE SysPhS-1.1: p.38: 10.9.4 Modelica modeling, signal flow: Modelica code: the equation 'der(velocity)=(u-springcst*position)/m;' should use variable 'mass' not 'm' SysPhS-1.1 SysPhS, Modelica
ISSUE SysPhS-1.1: p.38: 10.9.4 Modelica modeling, signal flow: Modelica code: the keyword should be 'equation' not 'equations'. SysPhS-1.1 SysPhS, Modelica
ISSUE, PROPOSAL SysPhS-1.1: p.38: 10.9.4 Modelica modeling, signal flow: Suggest kick start Spring with something like 'position=5' (otherwise get flat line when run). SysPhS-1.1 SysPhS
ISSUE SysPhS-1.1: p.41: 10.9.8 Modelica modeling, physical interaction: Reference to 'the bindings in Figure 14' should probably be 'the bindings in Figure 26'. SysPhS-1.1 SysPhS
ISSUE SysPhS-1.1: p.42: 10.9.8 Modelica modeling, physical interaction: Modelica code has 'forcediff=springcst*lengthchg;' should be 'forcethru=springcst*lengthchg;' SysPhS-1.1 SysPhS, Modelica
ISSUE SysPhS-1.1: p.44: 10.10.3 Modelica modeling: Reference to 'The following Modelica code corresponds to Figure 15' should probably be 'to Figure 27'. SysPhS-1.1 SysPhS
ISSUE SysPhS-1.1: p.45: 10.11.2 SysML modeling: Reference to 'the units library in Figure 20, Subclause 11.2.2' is wrong SysPhS-1.1 SysPhS
ISSUE 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 SysPhS
ISSUE 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 State::entry, State::doActivity, StateMachine SysPhS, SysML, Systems Modeling Language
ISSUE SysPhS-1.1: p.47: 10.12.2 SysML modeling: TYPO: Incorrect spelling of RealInSignalElement (should be RealSignalInElement) and RealOutSignalElement (should be RealSignalOutElement) SysPhS-1.1 StateMachine SysPhS
ISSUE SysPhS-1.1: p.53: Figure 30: Incorrect references to RealInSignalElement, RealOutSignalElement, IntegerInSignalElement, IntegerOutSignalElement, BooleanInSignalElement, BooleanOutSignalElement (should be RealSignalInElement, RealSignalOutElement, ...) SysPhS-1.1 SysPhS