Figure 11-10: Continuous system example 1 {ELIDED PINS}

Gallery

Tutorial

TRAIL: The SysML-1.6 Hybrid SUV sample and specification diagrams in MagicDraw/Cameo (with annotations) [UNDERGOING UPDATE to SysML1.7]

Section

Section: SysML-1.6 specification diagrams: 11 Activities

Tags and keywords

UML keywords

ModelLibrary

rake icon

Activity

SysML keywords

ControlValueKind

ControlValueKind::disable

ControlValueKind::enable

SysML specification figure

SysML Activity Diagram

Slide kind

SysML Activity Diagram

This figure can't be consistently implemented due to multiple tool and specification issues including:

Claim: The ControlValue input to Monitor Traction without a Pin is invalid in 'Figure 11-10: Continuous system example 1' and multiple issues with ControlOperator

MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode for "elided Pin notation" instead of an abstract ObjectNode _symbol_ and 2 arrow _symbols_ (notations that are supposed to represent together 2 Pins and 1 ObjectFlow edge)

Click on the image to view it full size

Note also the workaround on the BrakePressure {stream} for:

MagicDraw/Cameo 19SP3: If Continuous or Discrete are applied to the underlying Parameter of an InputPin or an OutputPin the keywords «continuous» or «discrete» can't be displayed

MagicDraw/Cameo 19SP3: Continuous and Discrete have metaclass [ActivityEdge, ObjectNode, Parameter] not just [ActivityEdge, Parameter] (via Rate), so may be applied directly to Pin and ActivityParameterNode

Up next

Figure 11-11: Continuous system example 2 {ELIDED PINS}

Notes

[ISSUE] SysML-1.6: Multiple references to ControlValue should be ControlValueKind (known issue)

[ISSUE] MagicDraw/Cameo: Has ControlValue not ControlValueKind (due to known SysML spec issue)

[ISSUE, TOOL, WARNING] MagicDraw/Cameo: DO NOT use the ObjectNode menu item on Activity Diagrams ever!

[DISPLAY, ISSUE, TOOL, WARNING] Webel recommends when using MagicDraw/Cameo: AVOID the "elided Pin" abstract ObjectNode notation on Activity Diagrams, use explicit Pins!

[ISSUE, TOOL] MagicDraw/Cameo: ERROR: Incorrectly uses 2 ObjectFlow edges and a CentralBufferNode for "elided Pin notation" instead of an abstract ObjectNode _symbol_ and 2 arrow _symbols_ (notations that are supposed to represent together 2 Pins and 1 ObjectFlow edge)

[ISSUE] Claim: The ControlValue input to Monitor Traction without a Pin is invalid in 'Figure 11-10: Continuous system example 1' and multiple issues with ControlOperator

[ISSUE] MagicDraw/Cameo 19SP3: Continuous and Discrete have metaclass [ActivityEdge, ObjectNode, Parameter] not just [ActivityEdge, Parameter] (via Rate), so may be applied directly to Pin and ActivityParameterNode

[CAVEAT, DISPLAY, ISSUE, TOOL] MagicDraw/Cameo 19SP3: If Continuous or Discrete are applied to the underlying Parameter of an InputPin or an OutputPin the keywords «continuous» or «discrete» can't be displayed

Snippets (quotes/extracts)

[SysML-1.6] Figure 11-10 shows a simplified model of driving and braking in a car that has an automatic braking system.

[SysML-1.6] Turning the key on has a duration constraint specifying that this action lasts no more than 0.1 seconds.

[SysML-1.6] The Driving behavior outputs a brake pressure continuously to the Braking behavior while both are executing, as indicated by the «continuous» rate and streaming properties (streaming is a characteristic of UML behavior parameters that supports ...

[SysML-1.6] Brake pressure information also flows to a control operator that outputs a control value to enable or disable the Monitor Traction behavior.

[SysML-1.6] No pins are used on Monitor Traction, so once it is enabled, the continuously arriving enable control values from the control operator have no effect, per UML semantics.

[SysML-1.6] When the brake pressure goes to zero, disable control values are emitted from the control operator. The first one disables the monitor, and the rest have no effect.

[SysML-1.6] While the monitor is enabled, it outputs a modulation frequency for applying the brakes as determined by the ABS system.

[SysML-1.6] The rake notations on the control operator and Monitor Traction indicate they are further defined by activities, as shown in Figure 11-11 and Figure 11-12. An alternative notation for this activity decomposition is shown in Figure 11-13.

[UML-2.5.1] Control Pins are shown with the textual annotation {control} placed near the Pin symbol.

[UML-2.5.1] isControl : Boolean [1..1] = false Indicates whether the Pin provides data to the Action or just controls how the Action executes.

[fUML-1.4] If isControlType=true for an ObjectNode, ControlFlows may be incoming to and outgoing from the ObjectNode, objects tokens can come into or go out of the ObjectNode along ControlFlows, and these tokens can flow along ControlFlows reached downstream ...

[UML-2.5.1] ObjectNode::isControlType : Boolean [1..1] = false Indicates whether the type of the ObjectNode is to be treated as representing control values that may traverse ControlFlows.

[UML-2.5.1] A control Pin (with isControl=true) must have a control type (isControlType=true), so that they may be used with ControlFlows.

Related slides (includes other tutorials)

Related slides (backlinks, includes other tutorials)

SysML Activity extension stereotypes - REFERENCE CARD

SysMLv1.7 Activity extensions: ControlOperator and ControlValueKind: ADVANCED REFERENCE CARD

Visit also

Visit also (backlinks)

UML2/SysMLv1: A control Pin (a Pin with isControl = True) for a CallBehaviorAction does not have a corresponding Parameter

Flags