Resolution Sequence for Input Signals

Detection of Signal Updates

A block that possesses a reactive port listens for relevant updates in the input signal. A relevant update causes the block to react appropriately (for example, by opening a gate or generating a function call).

Example of Signal Updates and Reactions

The schematics below illustrate relevant updates and the blocks' corresponding reactions.

Signal Update That Causes a Switch to Select a Port

Signal Update That Causes a Gate to Open

Effect of Simultaneous Operations

An update in an input signal is often simultaneous with other operations in the same block or in other blocks in the model. The processing sequence for the set of simultaneous operations can influence the simulation behavior.

Example of Simultaneous Signal Updates

In the model below, two signal updates and one entity-generation event occur simultaneously and independently. The simulation behaves differently depending on the sequence in which it processes these events and their logical consequences (where the port selection event is a logical consequence of the update of the p signal and the gate opening is a logical consequence of the update of the en signal). Advancement of the newly generated entity is also a potential simultaneous event, but it can occur only if conditions in the switch, queue, and gate blocks permit the entity to advance.

Resolve the Set of Operations

For modeling flexibility, blocks that have reactive ports offer two levels of choices that you can make to refine the simulation's behavior:

  • The Resolve simultaneous signal updates according to event priority check box lets you choose the algorithm the application uses to resolve the reactions to signal updates, relative to other simultaneous operations in the simulation.

  • If you select Resolve simultaneous signal updates according to event priority, the algorithm relies on the relative values of a set of numerical event priorities. You must set the event priority values using parameters in various blocks in the model.

Specify Event Priorities to Resolve Simultaneous Signal Updates

If you select the Resolve simultaneous signal updates according to event priority option in a block that has a reactive port, and if the block detects a relevant update in the input signal that connects to the reactive port, then the application defers reacting to the update until it can determine which other operations are supposed to be simultaneous. Furthermore, the application sequences the reaction to the update using the numerical event priority that you specify.

Schematic Showing Application Processing

The next figure summarizes the steps the application takes when you select Resolve simultaneous signal updates according to event priority and the block has a relevant update in its input signal at a given time, T.

Processing for Numerical-Priority Events

Contrast this with the schematics in Processing for System-Priority Events and Processing for Immediate Updates.

The following blocks are exceptions to the processing sequence shown in the preceding graphic.

  • Event Filter

  • Signal-Based Function-Call Generator

  • Signal Latch

For the listed blocks, if you select the configuration parameter Prevent duplicate events on multiport blocks and branched signals in your model, the software uses the Event priority parameter to help Simulink® to sort blocks in the model. The software no longer schedules an event that you can view on the SimEvents® event calendar. The following graphic shows the processing sequence for these blocks.

Use of the Event Calendar

To defer reacting to a signal update, the block schedules an event ("Event X" in the schematic) on the event calendar to process the block's reaction. The scheduled time of the event is the current simulation time. The event priority of the event is the value of the Event priority or similarly named parameter in the block dialog box.

After scheduling the event, the application might perform other operations in the model at the current simulation time that are not scheduled on the event calendar. Examples of other operations can include updating other signals or processing the arrival or departure of entities.

Use of Event Priority Values

When the application begins processing the events that are scheduled on the event calendar for the current simulation time, event priority values influence the processing sequence. For details, see Processing Sequence for Simultaneous Events. As a result, the application is resolving the update or change in the input signal (which might be simultaneous with other operations in the same block or in other blocks) according to the relative values of event priorities of all simultaneous events on the event calendar. A particular value of event priority is not significant in isolation; what matters is the ordering in a set of event priorities for a set of simultaneous events.

Resolve Simultaneous Signal Updates Without Specifying Event Priorities

If you do not select the Resolve simultaneous signal updates according to event priority option in a block that has a reactive port, and if the block detects a relevant update in the input signal that connects to the reactive port, then the block processes its reaction using one of these approaches:

  • Defers reacting to the update until it can determine which other operations are supposed to be simultaneous. Furthermore, the application sequences the reaction to the update using an event priority value called a system priority, denoted SYS1 or SYS2.

    For details, see System-Priority Events on the Event Calendar.

  • Reacts upon detecting the update (shown as "immediately" in the schematic illustrating this approach). The reaction, such as generation of a function call in the Signal-Based Function-Call Event Generator block, is not deferred, is not scheduled on the event calendar, and has no event priority. As a result, you are not resolving the sequence explicitly.

    For details, see Unprioritized Reactions to Signal Updates.

System-Priority Events on the Event Calendar

The next figure summarizes the steps the application takes when you choose not to select Resolve simultaneous signal updates according to event priority in a block that uses system-priority events and that has a relevant update in its input signal at a given time, T.

Processing for System-Priority Events

Contrast this with the schematics in Processing for Numerical-Priority Events and Processing for Immediate Updates. The difference between using a system priority and specifying a numerical priority for the same event is that the system priority causes earlier processing; see Processing Sequence for Simultaneous Events.

The blocks that can use system-priority events, unlike the blocks that can perform immediate updates, are characterized by the ability to directly change the state of an entity, including its location or attribute:

  • Enabled Gate

  • Entity Departure Counter

  • Event-Based Entity Generator

  • Input Switch

  • Output Switch

  • Path Combiner

  • Release Gate

Unprioritized Reactions to Signal Updates

The next figure summarizes the steps the application takes when you do not select Resolve simultaneous signal updates according to event priority in a block that performs immediate updates and that has a relevant update in its input signal at a given time, T.

Processing for Immediate Updates

Contrast this with the schematics in Processing for Numerical-Priority Events and Processing for System-Priority Events.

The blocks that can perform immediate updates, unlike the blocks that can use system-priority events, are characterized by the ability to produce signal outputs as a direct result of signal-based events:

  • Discrete Event Inport

  • Signal Latch

  • Signal-Based Function-Call Event Generator

  • Signal-Based Function-Call Generator

For Further Information

Was this topic helpful?