I85PREP
⌘ K
OCSMP Model User study materials
OCSMP Model User study resources

The State Machine Nothing Dispatches To

OCSMP Model User · Put your knowledge to work in context.

All case studies

The State Machine Nothing Dispatches To

ValveCtl is a block with a proxy port cmd typed by IF_Valve, conjugated; IF_Valve declares receptions for OpenCmd and CloseCmd. The state machine ValveSM is owned by the Controls package as a standalone behavior. It is not listed as ValveCtl's classifierBehavior, and nothing in ValveCtl references it. ValveSM has states Closed, Opening, Open and Fault: Closed → Opening on OpenCmd; Opening → Open after(5 s); Opening → Fault on a change event [linePressure > 300]; Open → Closed on CloseCmd. In isolated simulation of ValveSM the OpenCmd trigger fires correctly. In the integrated model, sending OpenCmd to an instance's cmd port produces no state change and no error.

1. Explain why the integrated model is inert while the standalone simulation works.

Read the worked answer

A state machine only runs when there is an object whose behavior it is. Owned by a package, ValveSM is a reusable definition with no instance; it has no event pool, so nothing can be dispatched to it.

For port events to reach it, three things must line up:

  1. ValveSM must be the classifierBehavior of ValveCtl (or be invoked from a call-behavior action somewhere that runs). A block can have only one classifier behavior - check first whether an activity is already assigned, because silently replacing it is a real regression risk.
  2. The reception must be on the receiving side. cmd is conjugated, so ValveCtl is the receiver of OpenCmd. If the conjugation is wrong, ValveCtl is modelled as the sender and will never receive.
  3. The signal must actually arrive at the port from a connected sender - an unconnected port is a valid model that does nothing.

The standalone simulation proves only that the transition table is right. It says nothing about dispatch, which is a structural property of ValveCtl.

2. A reviewer claims the [linePressure > 300] transition is 'a guard, so it re-fires every scan'. Correct that, and state what the model needs for it to work at all.

Read the worked answer

A change event is not a level-triggered guard. It is generated when the Boolean expression becomes true - edge detection. Consequences the reviewer's mental model gets wrong:

  • If linePressure is already above 300 when Opening is entered, the event is generated on entry and the transition is taken immediately. That may be desirable, but it should be intended.
  • If the transition is taken and pressure stays high, re-entering Opening will not re-trigger until the expression goes false and true again. An operator who resets to Opening at 400 kPa will see the valve stuck in Opening and blame the state machine.
  • A triggerless transition with only a guard behaves like a change event in this respect; writing it as a change event makes the intent explicit.

What the model needs: linePressure must be a reachable property whose value is actually updated by something - a flow from a sensor part, a value property on the block, or an external input. A change event over a property no one writes is an expression that is never re-evaluated.

3. What does after(5 s) actually measure, and what happens if the Fault transition intervenes?

Read the worked answer

after(5 s) is relative to entry into the source state, not to system start and not to the last time the transition was evaluated.

Trace the timing:

  • Enter Opening at t=0; the timer is armed for t=5 s.
  • At t=3 s pressure exceeds 300 and Opening → Fault fires. The timer is discarded with the state exit.
  • Operator clears the fault, the machine re-enters Opening at t=4 s. The timer re-arms and expires at t=9 s, not t=5 s.

Two practical consequences:

  • Any test that assumes a fixed 5 s from the command will fail intermittently once the fault path is exercised. Write the acceptance criterion against entry time, or record the transition timestamps.
  • If Opening also has a do activity, the state's completion event competes with the time event: a do activity that overruns 5 s does not block the time event, but a completion transition from the same state will fire only when the activity finishes. Decide which one is meant to open the valve, and delete the other - having both is the most common source of 'it opened twice' reports.