|
|
|
| R2012a Documentation → SimEvents | |
Learn more about SimEvents |
|
| Contents | Index |
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
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.
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.
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.
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.
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.
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.
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.
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
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
Managing Simultaneous Events — Resolving race conditions in discrete-event simulations
Reactive Ports — What constitutes a relevant update at a reactive port
 | Choosing How to Resolve Simultaneous Signal Updates | Livelock Prevention |  |
Model electronic system architectures, process flows, and logistics as queuing systems or agent-based systems.
Get free kit| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |