Stateflow®

Using Bind Actions to Control Function-Call Subsystems

About Bind Actions

Bind actions in a state bind specified data and events to that state. Events bound to a state can be broadcast only by the actions in that state or its children. You can also bind a function-call event to a state to enable or disable the function-call subsystem that it triggers. The function-call subsystem enables when the state with the bound event is entered and disables when that state is exited. This means that the execution of the function-call subsystem is fully bound to the activity of the state that calls it.

Back to Top

Binding a Function-Call Subsystem to a State

By default, a function-call subsystem is controlled by the Stateflow chart in which the associated function call output event is defined. This association means that the function-call subsystem is enabled when the chart wakes up and remains active until the chart is deactivated. To achieve a finer level of control, you can bind a function-call subsystem to a state within the chart hierarchy by using a bind action (see Bind Actions).

Bind actions can bind function-call output events to a state. When you create this type of binding, the function-call subsystem that is called by the event is also bound to the state. In this situation, the function-call subsystem is enabled when the state is entered and disabled when the state is exited.

When you bind a function-call subsystem to a state, you can fine-tune the behavior of the subsystem when it is enabled and disabled, as described in the following sections:

• Handling Outputs When the Subsystem is Disabled

• Controlling Behavior of States When the Subsystem is Enabled

Handling Outputs When the Subsystem is Disabled

Although function-call subsystems do not execute while they are disabled, their output signals are available to other blocks in the model. If a function-call subsystem is bound to a state, you can hold its outputs at their values from the previous time step or reset the outputs to their initial values when the subsystem is disabled. Follow these steps:

1. Double-click the outport block of the subsystem to open its Block Parameters dialog box, as in this example:

   

2. Select an option for the field Output when disabled, as follows:

   Select:	To:
   held	Maintain most recent output value
   reset	Reset output to its initial value

3. Click OK to record the settings.

   Note   Setting Output when disabled is meaningful only when the function-call subsystem is bound to a state, as described in Binding a Function-Call Subsystem to a State.

Controlling Behavior of States When the Subsystem is Enabled

If a function-call subsystem is bound to a state, you can hold the subsystem state variables at their values from the previous time step or reset the state variables to their initial conditions when the subsystem executes. In this way, the binding state gains full control of state variables for the function-call subsystem.

Follow these steps:

1. Double-click the trigger port of the subsystem to open its Block Parameters dialog box, as in this example:

   

2. Select an option for the field States when enabling, as follows:

   Select:	To:
   held	Maintain most recent values of the states of the subsystem that contains the trigger port
   reset	Revert to the initial conditions of the states of the subsystem that contains this trigger port
   inherit	Inherit this setting from the function-call initiator's parent subsystem. If the parent of the initiator is the model root, the inherited setting is held. If the trigger has multiple initiators, the parents of all initiators must have the same setting, either all held or all reset.

3. Click OK to record the settings.

   Note   Setting States when enabling is meaningful only when the function-call subsystem is bound to a state, as described in Binding a Function-Call Subsystem to a State.

Back to Top

Example of How to Bind a Function-Call Subsystem to a State

The control of a Stateflow state that binds a function-call subsystem trigger is best understood through the creation and execution of an example model. In the following example, a Simulink model triggers a function-call subsystem with a function-call trigger event E bound to state A of a Stateflow chart.

The function-call subsystem contains a trigger port block, an input port, an output port, and a simple block diagram. The block diagram increments a count by 1 each time, using a Unit Delay block to store the count.

The Stateflow chart contains two states, A and B, and connecting transitions, along with some actions. Notice that event E is bound to state A with the binding action bind:E. Event E is defined for the Stateflow chart in the example with a scope of Output to Simulink and a trigger type of function-call.

The Block Parameters dialog box for the trigger port appears.

Notice that the States when enabling field is set to the default value reset. This resets the state values for the function-call subsystem to zero when it is enabled.

Notice also that the Sample time type field is set to the default value triggered. This value sets the function-call subsystem to execute only when it is triggered by a calling event while it is enabled.

Setting Sample time type to periodic enables the Sample time field below it, which defaults to 1. These settings force the function-call subsystem to execute for each time step specified in the Sample time field while it is enabled. To accomplish this, the state that binds the calling event for the function-call subsystem must send an event for the time step coinciding with the specified sampling rate in the Sample time field. States can send events with entry or during actions at the simulation sample rate. Therefore, for fixed-step sampling, the sample time you enter in the Sample time field must be an integer multiple of the fixed-step size. For variable-step sampling, there are no limits on what you can enter in the Sample time field.

Back to Top

Simulating a Bound Function-Call Subsystem

To see the control that a state can have over the function-call subsystem whose trigger event it binds, begin simulating the example model in Example of How to Bind a Function-Call Subsystem to a State. For the purposes of display, the simulation parameters for this model specify a fixed-step solver with a fixed-step size of 1. Take note of model behavior in the following steps, which record the simulating Stateflow chart and the output of the subsystem.

1. The default transition to state A is taken.

2. State A becomes active as shown.

   

   When state A becomes active, it executes its bind and entry actions. The binding action, bind:E, binds event E to state A. This enables the function-call subsystem and resets its state variables to 0.

   State A also executes its entry action, en:E, which sends an event E to trigger the function-call subsystem and execute its block diagram. The block diagram increments a count by 1 each time using a Unit Delay block. Since the previous content of the Unit Delay block is 0 after the reset, the starting output point is 0 and the current value of 1 is held for the next call to the subsystem.

3. The next update event from the Simulink model tests state A for an outgoing transition.

   The temporal operation on the transition to state B, after(10, tick), allows the transition to be taken only after ten update events are received. This means that for the second update, the during action of state A, du:E, is executed, which sends an event to trigger the function-call subsystem. The held content of the Unit Delay block, 1, is output to the scope as shown.

   

   The subsystem also adds 1 to the held value to produce the value 2, which is held by the Unit Delay block for the next triggered execution.

4. The next eight update events repeat step 2, which increment the subsystem output by 1 each time as shown.

   

5. On the 11^th update event, the transition to state B is taken as shown.

   

   This makes state B active. Since the binding state A is no longer active, the function-call subsystem is disabled, and its output drops to 0.

6. When the next sampling event occurs, the transition from state B to state A is taken.

   Once again, the binding action, bind: E, enables the function-call subsystem and resets its output to 0 as shown.

   

7. With the next 10 update events, steps 2 through 5 repeat, producing the following output:

   

Back to Top

Using Stateflow Logic with Binding

You can use Stateflow logic to control function-call subsystems that model C-like switch, if-else, for, and while statements in Simulink models. Although you can model switch behavior in a Stateflow chart, the generated code approximates the switch logic by using if-else statements.

For example, the following model demonstrates a Simulink switch statement with subsystems controlled by bind actions:

In this model, the Stateflow chart controls three subsystems, S1, S2, and S3, through the bind actions for three states, A, B, and C, respectively. In this example, the value of the case argument c determines the subsystem to execute. State A becomes active and stays active when c is 0. State B becomes active and stays active when c is 1. State C becomes active and stays active when c has any other value.

When state A is active, the event S1 is bound to state A, which enables subsystem S1. The entry and during actions for A broadcast the event S1 whenever the model is updated for sampling. This means that while A is active, the subsystem S1 is executed for each sample time. The same applies to subsystem S2 for state B, and to subsystem S3 for state C.

The generated code for this model does not contain switch statements. Instead, it uses if-else logic, as represented by the following pseudocode:

if (c==0)
   if (!in(A))
      subsystem S1
else if (c==1)
   if(!in(B))
	     subsystem S2
else
	  if (!in(C))
       subsystem S3

You can modify the previous Stateflow chart to control a Simulink model with an if-else statement, as shown.

In this example, State A becomes active and stays active when the condition Acon is true. State B becomes active and stays active when the condition Bcon is true and the condition Acon is false. State C becomes active and stays active when both conditions Acon and Bcon are false. This creates the following if-else statement in the Simulink model:

if (Acon)
     subsystem S1
elseif (Bcon)
     subsystem S2
subsystem S3

Back to Top

Avoiding Muxed Trigger Events with Binding

The simulated example in Simulating a Bound Function-Call Subsystem shows how binding events gives control of a function-call subsystem to a single state in a Stateflow chart. This control can be undermined if you allow other events to trigger the function-call subsystem through a mux. For example, the following Simulink model defines two function-call events to trigger a function-call subsystem through a mux:

In the Stateflow chart, E1 is bound to state A, but E2 is not. This means that state B is free to send the triggering event E2 in its entry action. When you simulate this model, you receive the following output:

Notice that broadcasting E2 in state B changes the output, which now rises to a height of 10 before the binding action in state A resets the data.

Note   Binding is not recommended when users provide multiple trigger events to a function-call subsystem through a mux. Muxed trigger events can interfere with event binding and cause undefined behavior.

Back to Top

Checking State Activity

Using Vectors and Matrices in Stateflow Charts