OCSMP Model User: The Proxy Port That Swallows Commands

The Proxy Port That Swallows Commands

A thermal control subsystem has a Controller block with a proxy port pCmd typed by IF_Heater and marked conjugated. A connector runs from Controller.pCmd to Heater.pCmd, where Heater.pCmd is a full port typed by IF_Heater with no conjugation. IF_Heater declares an in flow property heatOn : Boolean and an operation setDutyCycle(). The Controller owns four parts typed Heater, declared as a single part property h : Heater [1..4], and the connector terminates on that one part property. Controller has no internal connectors from pCmd to h. In integration test, calls arriving at pCmd return normally but no duty cycle ever changes and no error is raised.

1. Explain the direction and conjugation semantics on this connector, and say what would break if the conjugation were removed.

Read the worked answer

Conjugation inverts every feature direction of the type, read from the perspective of the block that owns the port.

Controller.pCmd is conjugated, so relative to Controller, heatOn is an out flow property (Controller sends) and the reception/operation set is what Controller requests.
Heater.pCmd is not conjugated, so relative to Heater, heatOn is in (Heater receives) and setDutyCycle() is what Heater provides.
The connector therefore joins out to in and is well-formed. Any item flow drawn on it must convey a classifier matching the flow property's type.

If the conjugation on pCmd were removed, both ends would present heatOn as in, and the connector would join in-to-in: the tool would either reject the connector or flag the item flow direction conflict. If the real intent was for Controller to receive status from the heater, that must be added as a separate flow property on the interface, not achieved by dropping conjugation.

2. Why does the model accept the wiring yet produce no observable behavior? Distinguish full and proxy ports here.

Read the worked answer

The port kind is a claim about where the behavior lives.

A full port means the interface features are features of the owning block: Heater.pCmd full means Heater itself realizes setDutyCycle().
A proxy port means the block does not implement the interface; it forwards to internal parts that do. Controller.pCmd proxy asserts 'some part of Controller handles this'.

Controller has a proxy port but no internal connector from pCmd to anything, and no part that realizes IF_Heater is wired to it. The model is therefore incomplete: a request arriving at pCmd has no destination. In simulation the request is accepted at the boundary and dropped - exactly the silent symptom observed, and the reason no error is raised.

Fix one end or the other, deliberately: either keep the proxy port and add a connector pCmd → h.pCmd (delegation, with h's type realizing IF_Heater), or make pCmd a full port and give Controller its own behavior realizing IF_Heater.

3. The connector terminates on a part property with multiplicity 1..4. Is that legal, and what should the modeler decide?

Read the worked answer

It is legal but semantically loaded. A connector end bound to a part property with multiplicity 1..4 denotes up to four links; all four Heater instances receive the same heatOn value. The tool will not complain, so the decision is entirely a modelling judgement.

If heatOn is a broadcast command ('all heaters on'), fan-out to four heaters is correct - but say so, in a comment or in the interface name, because the next reader will assume per-unit control.
If duty cycle is set per heater, the single connector is wrong. Replace it with a distribution element or an indexed connection and put an identifier on the flow so each Heater can filter what applies to it.
Four explicit parts h1..h4 with four connectors also works but hard-codes a count that will change.

Decide on interchangeability of heaters, not on what the tool accepts.