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

p.147 Figure 11-10: Continuous system example 1 shows an object flow with an object token of type ControlValue (should probably be ControlValueKind) from a ControlOperator Enable on Brake Pressure > 0 to Monitor Traction.

The notation shown is consistent with UML-2.5.1 "elided Pin" notation:

'An object flow is notated by an arrowed line. In Figure 15.9, upper right, the two object flow arrows denote a single object flow edge between two pins in the underlying model, as shown in the lower middle of the figure.'

The relevant UML-2.5.1 Figure 15.9 ObjectFlow notations is attached.

Please note how it describes the notation as two object flow arrows (notational symbols that do not correspond one-to-one to ActivityEdge elements, but rather to one ObjectFlow edge). Note also how it says there are two Pins in the underlying model.

At least one tool implements this notation incorrectly and uses 2 ObjectFlows and a CentralBufferNode instead of two arrows and a rectangular symbol representing any ObjectNode sub-type

SysML-1.6 p.146 states:

Brake pressure information also flows to a control operator that outputs a control value to enable or disable the Monitor Traction behavior. 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.

It is not permissible in UML-2.5.1 to have 'No pins used on Monitor Traction'. And if there were no Pins, it is not clear how {contro\l} is indicated in Figure 11-10, because, from UML-2.5.1:

Control Pins are shown with the textual annotation {control} placed near the Pin symbol.

If there are 'No pins used on Monitor Traction' the {control} notation can't be supported.

Further: SysML-1.6 p.127 states:

A control value is an input or output of a control operator ..

If there is any sense in which it can be "input" to another type of Action (the controlled one), this should also be stated.

On SysML-1.6 p.140 it is not made clear what 'control parameters' are:

Pins for control parameters are regular pins, not UML control pins.

If they are parameters of a Behavior with the ControlOperator stereotype applied this should be clearly stated. Otherwise, the (necesssary) {control} input Pin required on Monitor Traction in Figure 11-10 could be considered to have an underlying "control parameter" that contradicts the above rule.

A partial solution (apart from suggested expansions of the explanatory text) would be to at least use an explicit {control} Pin on Monitor Traction and remove the claim that it has no Pins.