Lesson 19, event-gated transitions with optional guards versus condition-monitored transitions

Hi,

Still trying to get my lesson 18 model to run in the lesson 19 simulator.
It seems I have hit some sort of fundamental issue.
The state transitions in lesson 18, my own as well as the provided solution have been written as condition-monitored transitions. For example (from the provided solution):
state clear;
accept when visibility < lowVisibility and windSpeed > highWindSpeed then foggyAndWindy; accept when visibility < lowVisibility then foggy;
accept when windSpeed > highWindSpeed then windy;

So when the system is in de clear state, it continuously evaluates the three conditions (triggered by changes in the values of visibility and windSpeed), until one is true and the system will transition to that state.

The example file of lesson 19 uses a event-gated with a guard condition mechanism to transition to a next state. For example (flying state of L19_State_Simulation.sysml):
state flying {
doc
/* Cruising flight. Normal forward flight operations. */
}
accept UpdateFlightData if groundSpeed < 2 [m / s] then hovering;
accept StartLanding then descending;

So if the system is in the flying state and the UpdateFlightData event happens, the system checks if groundSpeed is smaller than 2 m/s and if true, transitions to hovering.
This event-gated with a guard condition seems to be used everywhere in L19_State_Simulation.sysml.

For a simulation point of view the event-gated with a guard condition makes a lot sense, something only happens based on event.

Does this means we need another type of simulator for systems that use condition-monitored transitions, or is the lesson here try to avoid them and use a event-gated with a guard condition mechanism when possible?

(According to Claude, the L19 simulator script only supports event-gated transitions - it doesn’t have the continuous evaluation logic needed for condition-monitored transitions)

Hello Maurice,

You are right - this is due to the simulator. SysML state machines blend some execution models, and not all simulators support all of these. I think it wouldn’t be hard to extend the evaluation logic to allow for change monitoring, given that you update the values manually.

The key point is that both approaches are correct. The change event variant is more elegant, but the event-gated one is more simulator-friendly.

Vince