Documentation Center

  • Trials
  • Product Updates

SimEvents Release Notes

R2014a

Bug Fixes

R2013b

Bug Fixes

R2013a

New Features

Drag-and-drop block insertion and one-click connection for entity lines

In R2013a, SimEvents® adds capabilities that enable you to quickly insert blocks and connect entity lines.

Drag-and-drop block insertion

To add a new block to an existing entity line, you can now drag the block from the library directly into the existing line. SimEvents automatically inserts the block and connects entity lines. For more information, see Insert Blocks.

One-click entity line connection

You can now connect an entity line between two blocks with a mouse click. To connect an entity line, select the source block. Ctrl+click the destination block. SimEvents connects the blocks. If necessary, the software also routes the connecting line around intervening blocks or lines. For more information, see Connect Blocks.

Available Attributes list for Set Attribute and Get Attribute blocks

For the Set Attribute and Get Attribute blocks, you can now select attributes that you want to access on the incoming entity from a list. In previous releases, you manually specified existing attributes that you wanted to access.

The new list—Available Attributes—displays attributes from entity paths entering the block.

If no attributes exist on entity paths entering the block, the list is empty.

To access an attribute on the incoming entity, select the attribute in the list and click the Add selected attribute to table button, .

The selected attribute moves to the Set Attribute table.

For more information, see Set Attribute and Get Attribute.

Entity attribute names visible in SimEvents blocks while editing the model

Some SimEvents blocks can use entity attributes as parameter values. To specify attributes for such blocks to use, in the block dialog box you can now select attributes on incoming entity paths from a list. In previous releases, you manually entered the attribute name.

The enhancement applies to the following blocks that can use attributes as parameter values:

  • Infinite Server

  • N-Server

  • Single Server

  • Attribute Scope

  • X-Y Attribute Scope

  • Output Switch

  • Schedule Timeout

Each of these blocks has a parameter that specifies that the next parameter in the dialog box uses an attribute. In this example, the Single Server block Service time from parameter is set to Attribute.

Each of the listed blocks has a parameter that you set to Attribute or From Attribute, similar to the Single Server block Service time from parameter.

The Attribute name list displays attributes that you can access on the incoming entity.

Timing tags visible in SimEvents blocks while editing the model

Some SimEvents blocks access timing tags from incoming entity paths. To specify a timing tag for the block to access, you can now select from a list of available timing tags.

In previous releases, you manually entered the timing tag.

The enhancement applies to the following blocks:

  • Cancel Timeout

  • Schedule Timeout

  • Read Timer

  • Start Timer

Context-sensitive help on block dialog boxes

SimEvents block dialog boxes now have context-sensitive help. To access context-sensitive help, right-click a parameter label and select What's This?

R2012b

New Features, Bug Fixes

Port Data Types display option that provides in-model view of SimEvents entity types and structures

When you compile your SimEvents model, you can now visually inspect the progress of each entity type in the model, and any changes to its structure, as it progresses through the model.

An entity type is the identification tag associated with any block in your SimEvents model that generates new entities. Each new entity that originates in such a block receives this tag.

If an entity has acquired attribute, timeout or timer data, the entity has a structure. If entities pass through multiple Set Attribute blocks that attach attribute data, or if you use an Entity Combiner block to combine data-carrying entities, entity structures might quickly become complex. Therefore, before simulation, you might want to inspect entity structures at various points in the model.

To help you to inspect entity structures, SimEvents uses the existing Port Data Types display option in Simulink®. If you enable this option for your model, the software shows all data types in the model, including SimEvents entity types. When you hover your cursor over an entity type label, the software displays a tooltip that shows the structure of the entity type at that point in the model.

To show labels for entity types, in the model editor, select Display > Signals & Ports > Port Data Types.

Model update and improvement checks in Upgrade Advisor and Model Advisor

The existing Model Advisor checks for SimEvents are renamed.

Old NameNew Name
Check model for legacy SimEvents blocksCheck model and local libraries for legacy SimEvents blocks
Check SimEvents model for implicit event duplicationCheck for implicit event duplication caused by SimEvents blocks

For more information about:

Also, one of the ways in which you use the Model Advisor to access the SimEvents checks has changed.

The Model Advisor groups all checks in two ways:

  • By product

  • By task

As in the previous release, you can access the SimEvents checks from either group. However, when you use the By Task group to access the SimEvents checks, you see different behavior.

To access the SimEvents checks from the By Product group, select Model Advisor > By Product > SimEvents.

To access the SimEvents checks from the By Task group, first select Model Advisor > By Task > Upgrading to the Current Simulink Version.

Upgrading to the Current Simulink Version now contains a single task, Open the Upgrade Advisor. If you choose this option, a new Simulink tool, the Upgrade Advisor, opens.

The graphic shows the SimEvents checks in Upgrade Advisor. In the previous release, these checks were directly listed under Upgrading to the Current Simulink Version in the Model Advisor.

For more information about the Upgrade Advisor, see Consult the Upgrade Advisor in the Simulink documentation.

N-Server block options to pause, force service completion, and monitor server occupancy

The dialog box for the N-Server block has a new tab, Service control. The service control feature lets you use an input signal to disable servers in the block, and, while they are disabled, apply a service change such as pausing or forcing service completion.

When you select Allow service control, the block dialog box displays additional options. You can use these options to specify the behavior of disabled servers.

By default, Service change upon disabling is set to Pause. When you click OK, the N-Server block displays an additional input port, pause.

When you input a positive signal to the pause port, the software disables all servers in the block. While this input signal remains positive, any occupied servers retain their entities and the software pauses the remaining service time for each server. When the signal at the input port becomes nonpositive, each server resumes service.

You can also set Service change upon disabling to Force complete. In this case, when you click OK, the N-Server block displays an additional input port, complete.

When the signal entering the complete port becomes positive, the software:

  • Disables all servers.

  • Immediately completes service in all occupied servers.

  • Resets the remaining service time in all servers.

If no blockage exists at the entity output port of the N-Server block, entities immediately advance from occupied servers to downstream blocks. When the signal at the input port becomes nonpositive, normal behavior of the N-Server block resumes.

If you select Block entity entry to disabled servers, while the signal at the pause or complete port is positive, servers cannot accept entities.

To help you to monitor server occupancy during the simulation, the Statistics tab of the N-Server block has a new parameter.

Selecting Server occupancy, so adds a signal output port labeled so to the block.

The so port outputs a vector of values. Each element of the vector indicates the status of the correpsonding server in the N-Server block. If a server is unoccupied, the value of the correpsonding vector element is 0. If a server is occupied, the vector element has a value of 1.

Event-based signal port connecting directly to Simulink Constant block without Gateway block

You can connect the signal input port of a SimEvents block directly to a Simulink Constant block that has a constant (Inf) sample time. In previous releases, to make this connection, you needed to insert a Timed to Event Signal block from the SimEvents Gateways library between the Constant block and the SimEvents block.

To connect any other time-based source to a SimEvents block, a gateway block is still required.

New examples

In this release, the following examples were added:

NameModel

Supervisory Control of a Conveyor Belt System

sedemo_airport_conveyor

R2012a

New Features, Bug Fixes, Compatibility Considerations

New Configuration Parameter for Prevention of Implicit Event Duplication

A new configuration parameter, Prevent duplicate events on multiport blocks and branched signals, has been added in this release. This parameter eliminates a condition known as multifiring that might exist in SimEvents models with particular block configurations. Multifiring is an implicit result of the way that the software executes such block configurations and causes duplication of events when the model is simulated. You can find Prevent duplicate events on multiport blocks and branched signals in the Configuration Parameters dialog box of your model.

Compatibility Considerations

Compatibility Considerations

If you use the R2012a software to open a SimEvents model created in a release prior to R2011b, you see the configuration parameter Prevent duplicate events on multiport blocks and branched signals and can select it, but the configuration parameter does not function. To enable the functionality of this parameter in a model created in a release prior to R2011b, first use the seupdate function to migrate the model to the latest version of the software. When the migration process is complete, in the SimEvents pane of the Configuration Parameters dialog box, select the Prevent duplicate events on multiport blocks and branched signals check box.

Support for Fixed-Step Solvers

Support for fixed-step solvers in SimEvents models has been added in this release. In previous releases, SimEvents models could be used with only variable-step solvers.

Compatibility Considerations

Compatibility Considerations

  • If you do not select the configuration parameter Prevent duplicate events on multiport blocks and branched signals in your model, you cannot set the solver type to Fixed-step.

  • If you use the R2012a software to open a SimEvents model created in a release prior to R2011b, you see the configuration parameter Prevent duplicate events on multiport blocks and branched signals and can select it, but the configuration parameter does not function. To enable the functionality of this parameter in a model created in a release prior to R2011b, first use the seupdate function to migrate the model to the latest version of the software. When the migration process is completed, in the SimEvents pane of the Configuration Parameters dialog box, select the Prevent duplicate events on multiport blocks and branched signals check box.

Enhanced Migration Workflow

Model Advisor Checks for SimEvents Models

The Simulink Model Advisor now checks your SimEvents model for certain issues that can be resolved either by migrating the model to the latest version of the software or by enabling functionality that is available in the latest version. You can use these Model Advisor checks as a starting point in the migration workflow for your model.

Use the Model Advisor checks for SimEvents to:

  • Check whether your model contains legacy blocks. Legacy blocks are blocks from a version of SimEvents prior to 4.0 (R2011b). If you have legacy blocks in your model, your model does not have the benefit of feature updates and modeling syntax changes in the latest version of the software. If this Model Advisor check detects that your model contains legacy blocks, it instructs you to use the seupdate function to migrate your model to the latest version of the software.

  • Check whether you have selected the configuration parameter Prevent duplicate events on multiport blocks and branched signals in your model. Prevent duplicate events on multiport blocks and branched signals resolves issues related to event duplication in SimEvents models. If the Model Advisor check detects that you have not selected this configuration parameter in your model, you can instruct the Model Advisor to select it.

Visual Appearance of Legacy Blocks

Legacy blocks are blocks from a version of SimEvents prior to 4.0 (R2011b). If your model contains legacy blocks, the software now visually labels these blocks so that when you view the model in the model editor, you can easily identify them. The software marks legacy blocks by placing an orange label, legacy, in the lower left-hand corner of the block. This visual marker helps you assess whether you need to use the seupdate function to migrate your model to the latest version of SimEvents.

Enhanced seupdate Migration Utility

The function seupdate was introduced in R2011b. The seupdate function is a migration utility that migrates a SimEvents model from a release prior to R2011b to the current release. This migration utility updates SimEvents and Simulink blocks. As necessary, it might also add gateway blocks to indicate transitions between event-based and time-based computational components of your model.

In this release, the following enhancements have been made to the seupdate function:

  • Prior to model migration, software automatically backs up your model and associated libraries.

  • Enhanced update report identifies conditions in your model that cause migration to fail and provides you with instructions to resolve the failure.

  • Prior to running seupdate, you no longer have to open your model . The software automatically opens the model.

  • Software checks for legacy queue blocks in your model and provides you with instructions to see if simulation results produced by these queue blocks will change as a result of updating the model.

Enhanced Visibility of Impact when Saving Models at Earlier Versions

If you use the Save as type: drop-down list to save your model at a version of SimEvents prior to 4.0 (R2011b), you now receive a warning in the MATLAB® command window. This new warning informs you that the software has replaced unsupported blocks with empty subsystem blocks and that a loss of functionality in the model is likely to result. The message provides you with instructions to resolve the problem.

The software also now marks any unsupported blocks that it replaces with the text Replaced so that you can easily identify the replaced blocks when you open your model.

Changes to Modeling Semantics

Gateway Blocks Support Buses

You can now connect Simulink bus signals to gateway blocks in a SimEvents subsystem. In previous releases, if you connected a bus signal to a gateway block you saw an error message.

You can also now use the following blocks from the Simulink block library to manipulate bus signals in a SimEvents subsystem:

  • Bus Creator

  • Bus Selector

  • Bus Assignment

Compatibility Considerations

  • In this release, you can connect a Simulink bus signal to only a SimEvents gateway block.

  • If the SimEvents subsystem contains blocks from a previous release, you cannot connect a bus signal to a SimEvents gateway block. Before using bus signals in your model, first use the seupdate function to migrate your model to the latest version of the software.

  • You can only use a bus signal in a SimEvents subsystem if you select the configuration parameter Prevent duplicate events on multiport blocks and branched signals in your model. After you use the seupdate function to migrate your model to the latest version of the software, you can enable this configuration parameter.

Enhanced Support for Simulink Subsystems

You can now use SimEvents blocks in Simulink Nonvirtual and Variant Subsystems, observing some specific guidelines, and in Simulink Virtual Subsystems without restriction. For more information, see SimEvents Support for Simulink Subsystems.

Compatibility Considerations

  • The only type of nonvirtual subsystem in which you can place SimEvents blocks is an Atomic Subsystem. You can only place SimEvents blocks in an Atomic Subsystem if you first select the configuration parameter Prevent duplicate events on multiport blocks and branched signals.

  • If you use the R2012a software to open a SimEvents model created in a release prior to R2011b, you see the configuration parameter Prevent duplicate events on multiport blocks and branched signals and can select it, but the configuration parameter does not function. To enable the functionality of this parameter in a model created in a release prior to R2011b, first use the seupdate function to migrate the model to the latest version of the software. When the migration process is completed, in the SimEvents pane of the Configuration Parameters dialog box, select the Prevent duplicate events on multiport blocks and branched signals check box.

Changed Use of Event Priority Parameter

When you select the configuration parameter Prevent duplicate events on multiport blocks and branched signals in your model, the behavior of the Event priority parameter of the following blocks changes.

  • Event Filter

  • Signal-Based Function-Call Generator

  • Signal Latch

When you select the configuration parameter Prevent duplicate events on multiport blocks and branched signals, the software uses the Event priority parameter of the blocks in the preceding list to help Simulink sort blocks in the model. For these blocks, the software no longer schedules an event that you can view on the SimEvents event calendar.

Compatibility Considerations

  • You do not see the changed behavior of the Event priority parameter for the listed blocks unless you select the configuration parameter Prevent duplicate events on multiport blocks and branched signals in your model.

  • If you use the R2012a software to open a SimEvents model created in a release prior to R2011b, you see the configuration parameter Prevent duplicate events on multiport blocks and branched signals and can select it, but the configuration parameter will not function. To enable the functionality of this parameter in a model created in a release prior to R2011b, first use the seupdate function to migrate the model to the latest version of the software. When the migration process completes, in the SimEvents pane of the Configuration Parameters dialog box, select the Prevent duplicate events on multiport blocks and branched signals check box.

  • If you do not select the configuration parameter Prevent duplicate events on multiport blocks and branched signals in your model, there is no change in the behavior of the Event priority parameter from previous releases. In previous releases, the software used the Event priority of each block to determine the order in which it processed events. You can use the SimEvents event calendar to view the events that the software has scheduled.

Block Library Changes

New Blocks

The Time-Based Function-Call Generator block has been added to the Generators/Function-Call Generators library.

Compatibility Considerations

To use the Time-Based Function-Call block in your SimEvents model, use the seupdate function to migrate the model to the latest version of the software.

Changes to Block Parameters

An extra diagnostic parameter, Use of signals awaiting update during function call: has been added to the Entity Departure Function-Call Generator block. This new parameter is visible in the Block Parameters dialog box, when you set the value of the Timing of function call f1: parameter of the block to Before entity departure. This new parameter does not function. however, if you do not also select the configuration parameter Prevent duplicate events on multiport blocks and branched signals in your model. When you configure the block in this way to generate a function-call before an entity departs the block, the function-call event might use signal values that are still awaiting update. If this situation arises, the new diagnostic parameter Use of signals awaiting update during function call: specifies the action you want the software to take.

You can select the following values for this parameter:

Value of Use of signals awaiting update during function call: parameterSoftware Action
noneNo action. Simulation runs normally.
warningWarning generated in MATLAB command window. Simulation still runs.
errorError generated in MATLAB command window. Simulation does not run.

The default value of the Use of signals awaiting update during function call: parameter of the Entity Departure Function-Call Generator block is error.

Compatibility Considerations

The configuration parameter Use of signals awaiting update during function call: of the Entity Departure Function-Call Generator block is not available in versions of this block from previous releases. To use this parameter, use the seupdate function to migrate the model that contains the Entity Departure Function-Call Generator to the latest version of the software.

Functions Being Removed

Affected FunctionWhat Happens When You Use the Function?Use This Instead
simeventsstartupNo longer works. You see a message in the MATLAB command window to tell you that no changes are made to your model.In the Configuration Parameters dialog box, manually choose settings appropriate for your discrete-event model.
simeventsconfigStill works. Function will be removed in a future release.In the Configuration Parameters dialog box, manually choose settings appropriate for your discrete-event model.

Demos

New Demo

The demo listed in the following table has been added in this release.

NameModel
Effects of Communication Delays on an ABS Control SystemEffects of Communication Delays on an ABS Control Systemsedemo_absbrake_can.mdl

Demos Removed

The demos listed in the following table have been removed in this release.

NameModel

Asynchronous Clock Domains

sedemo_async_clocks.mdl

Asynchronous Execution of a Stateflow Chart

sedemo_async_stateflow.mdl

R2011b

New Features, Bug Fixes, Compatibility Considerations

Major Changes to Discrete-Event Modeling

This release contains a number of improvements and changes in the software:

  • Enhanced modeling syntax clearly differentiates event-driven from time-driven components.

  • Opt-in upgrade workflow helps migrate models to leverage enhanced modeling syntax.

  • Entity and signal animation enable better insight into event-based execution.

  • Improved simulation speed and memory performance scales to support large models.

  • Increased support for Simulink blocks from Math and Logic libraries directly in event-driven computations.

  • Support for MATLAB Function and Stateflow Chart blocks to integrate MATLAB algorithms and control logic into discrete-event models.

  • New Event Filter block can be combined with Atomic Subsystem blocks to define custom event-triggered computational components.

Compatibility Considerations

To take advantage of the new modeling syntax in models and libraries built prior to V4.0 (R2011b), you must follow a conversion procedure using the new command, seupdate. This command:

  • Runs slupdate to perform all upgrades related to Simulink in the models.

  • Replaces SimEvents and Simulink blocks with their R2011b counterparts.

  • Replaces instances of the Discrete Event Subsystem block with the Simulink Atomic Subsystem block.

  • Inserts new gateway blocks to delineate the boundaries between event-based portions and time-based portions of the model.

After running seupdate, you might notice small changes in model behavior as a result of the refinements to the event-based modeling semantics. Verify the operation of your model and, if necessary, modify it. For further information, see Migrating SimEvents Models.

    Note:   The modeling paradigm from releases prior to R2011b continues to work. You can upgrade your models at any appropriate time. To continue to create or work with models from previous releases, use the simevents('3') command to access the block library from the previous release.

Modeling Syntax Enhancements

Gateway Blocks

The SimEvents library has new blocks that help delineate the boundary between event-based and time-based signals. and event-based based and time-based function-calls. The new Gateways sublibrary contains these blocks:

Input Port Styles

After you compile a model, all blocks with event-based signal inputs show an empty arrowhead to indicate that the blocks are executing in the event-based domain.

Simulink Blocks in Event-Based Computations

The following Simulink blocks can now operate directly on event-based computations. In previous releases, you had to contain these blocks in a discrete-event subsystem.

In addition, you can connect a block from the SimEvents Signal Generator library to a supported Simulink block that has only one input port.

Atomic Subsystem and Event Filter for Better Control on Event-Based Execution

The Simulink Atomic Subsystem block replaces the Discrete Event Subsystem block. The Atomic Subsystem blocks ensures that a set of blocks participate in event-based execution. Additionally, you can use the new Event Filter block to conditionalize, suppress, and prioritize execution of Atomic Subsystem blocks participating in event-based execution.

Animation and Debugging Enhancements

The SimEvents Debugger has been updated to incorporate an animation capability that shows both entity movement and event-based signal execution. The following command facilitates animation in the debugger:

  • The new sedb.animate command facilitates animation in the debugger. sedb.animate enables and disables animation, and controls the animation speed.

The debugger has several new and refined capabilities:

  • Sets entity breakpoints.

  • Supports multiple event calendars, one for each discrete-event system that your model might have.

  • Entries for gateway, event filter, function-call generation blocks

  • Head-of-queue-change event for queue blocks (NewHeadOfQueue).

  • Sorted order for blocks is displayed. You can now view the sorted order for blocks either in the debugger or the Simulink editor. To enable the sorted order of blocks in a model, in the Simulink editor, select Format > Block Displays > Sorted Order.

  • Debugger session function updates are:

    • sedb.enbreak, a new command, that breaks on any operation involving a given entity.

    • sedb.blklist lists gateway blocks and Simulink blocks.

    • sedb.detail has an option to show signal updates.

    • sedb.evcal supports multiple event calendars.

    Note:   You cannot set breakpoints for Simulink controlled blocks.

For more information, see Animating Signals and Entities.

Changes in Blocks and Modeling Semantics

Change in Entity Arrivals at Empty Queue

The following blocks behave differently when an entity arrives at an empty queue, and process a new type of event on the event calendar:

In V4.0 (R2011b), when an entity arrives at a queue block:

  • The queue stores the entity.

  • The #n output signal, if present, is update to indicate the arrival of the entity.

  • The queue block schedules a NewHeadOfQueue event on the event calendar. The event time is the current simulation time. When executing this event, the queue attempts to advance the entity to the next block.

This behavior does not depend on whether the queue is empty or whether the arriving entity can advance. Even if the entity can advance to the next block with no time delay, the simulation might process other operations between the arrival and departure of the entity. For example, the sample time hit registered in the #n signal might cause other operations to occur before the entity departs.

In earlier versions, when an entity arrived at an empty queue and advanced to the next block, the entity advanced immediately. The simulation did not process other operations between the arrival and departure of the entity. From this release forward, the #n output signal from the queue block has a sample time hit, with a value of 1 to indicate the arrival of the entity. The SimEvents debugger does not show a NewHeadOfQueue event.

Compatibility Considerations

The queue blocks available from the SimEvents library include the R2011b behavior changes. If you do not upgrade your legacy models, the models use older blocks that do not include the R2011b behavior changes.

If you upgrade your legacy models, you might observe changes in simulation behavior as a result of the queue upgrades.

  • When an entity arrives at an empty queue and leaves the queue immediately, there is an additional sample time hit of the #n signal.

  • When an entity arrives at an empty queue, there is the potential for other operations to occur between the arrival and departure of the entity. The rules described in Processing Sequence for Simultaneous Events are still in effect. However, when an empty queue has an arrival followed by a departure at the same value of the simulation clock, sequences described there as arbitrary might be different between this version and earlier versions.

  • The new NewHeadOfQueue event changes the way the SimEvents debugger steps through your simulation. For example, if you execute sedb.step 10 times and those steps include a NewHeadOfQueue event, the 10th step reaches a different point in the simulation compared to an earlier version.

Arrival of Entity Placed at Head of Queue

When an entity arrives at a queue and becomes the new head of queue entity, the following blocks behave differently from previous releases. These blocks now process a new type of event on the event calendar:

In V4.0 (R2011b), when an entity arrives at a queue block:

  • The queue stores the entity.

  • The #n output signal, if present, isupdated to indicate the arrival of the entity.

  • The queue block schedules a NewHeadOfQueue event on the event calendar. The event time is the current simulation time. When executing this event, the queue attempts to advance the entity to the next block.

This behavior does not depend on whether the queue is empty or whether the arriving entity can advance. Even if the entity can advance to the next block with no time delay, the simulation might process other operations between the arrival and departure of the entity. For example, the sample time hit in the #n signal might cause other operations to occur before the entity departs.

In earlier versions, when an entity arrived at a queue and did advance to the next block, the entity advanced immediately. The simulation did not process other operations between the arrival and departure of the entity. The #n output signal from the queue block had a sample time hit, with a value of 1, to indicate the arrival of the entity. The SimEvents debugger did not show a NewHeadOfQueue event.

Compatibility Considerations

Only the queue blocks available from the SimEvents library include the R2011b behavior changes. If you do not upgrade your legacy models, the models use older blocks that do not include these behavior changes.

If you upgrade your legacy models, you might observe changes in simulation behavior:

  • When an entity arrives at a queue and leaves the queue immediately, there is an additional sample time hit of the #n signal.

  • When an entity arrives at a queue, there is the potential for other operations to occur between the arrival and departure of the entity. The rules described in Processing Sequence for Simultaneous Events are still in effect. However, when a queue has an arrival followed by a departure at the same value of the simulation clock, sequences described there as arbitrary might be different between this version and earlier versions.

  • The new NewHeadOfQueue event changes the way that the SimEvents debugger steps through your simulation. For example, if you execute sedb.step 10 times and those steps include a NewHeadOfQueue event, the 10th step reaches a different point in the simulation compared to an earlier version.

Change to Sorted Order of Hybrid Systems

SimEvents blocks now simulate in the appropriate order in hybrid systems. In previous releases, SimEvents blocks were scheduled to simulate at the end of a sorted list.

Discrete Event Signal to Workspace Block Records Initial Value

When the Discrete Event Signal to Workspace block creates a workspace variable, it includes the initial value of the signal, if any. In earlier versions, the workspace variable did not include the initial value of the signal.

Compatibility Considerations

One or more initial values are now recorded. There is at least one more data entry at time 0.

Statistical Output Signals Have Updates Throughout Simulation

When a SimEvents block has built-in capabilities to produce statistical output signals, such as the number of entities that have departed from the block, the corresponding parameter in the block dialog box has a check box to indicate on and off. The blocks available from the SimEvents library no longer offer the Upon stop or pause option.

Compatibility Considerations

If you use the seupdate function to update a legacy model in which a SimEvents block has a parameter set to Upon stop or pause, the function sets the corresponding parameter in the replacement block to On. As a result, the signal has sample time hits at simulation times that do not necessarily correspond to the end of the simulation or a time at which you pause the simulation.

    Tip   If you want to create a variable in the MATLAB workspace containing the final value of the signal, use the To Workspace or Discrete Event Signal to Workspace block. In either block, set the Limit data points to last parameter to 1.

Configuration Parameter Race Condition Detection Changes

The default values of the SimEvents > Diagnostics parameters have changed. You can now create better models with better race condition checking.

ParameterNew ValueOld Value
Attribute output delayed relative to entitieserror warning
Response to function call delayed relative to entitieserror warning
Statistical Output Delayed Relative to Entitiesnonewarning

Related to these changes, the simeventsconfig has been updated. The simeventsconfig command now displays a list of all the parameter values that it can change, and then prompts you to enable these changes.

Compatibility Considerations

Because of the more stringent default race conditions diagnostics, existing models that generated warnings now generate errors and do not work. Modify your models as appropriate.

Block, Event, and Entity Identifiers

When you use seupdate to update a model from a previous release, the block, event, and entity identifiers might change from those in the original model.

Compatibility Considerations

If you have existing scripts or applications that use block, event, or entity identifiers in the debugger, update them to use the new identifiers. To determine the new identifiers, manually debug the model with the debugger.

SimEvents Support for Variant Subsystems

A model cannot contain a Variant Subsystem block that contains SimEvents blocks. In a discrete-event system, a Variant Subsystem block can only contain Simulink blocks that the SimEvents software supports. See Blocks That Support Event-Based Input Signals for a list of these blocks.

Discrete Event Signal to Workspace Block Can Reside in Atomic Subsystem

The Discrete Event Signal to Workspace block available from the SimEvents library can reside in any atomic subsystem. In previous releases, the block had the restriction described in Discrete Event Signal to Workspace Block Clarifies Timing.

Set Attribute and Get Attribute Blocks Can Process at Most 32 Attributes

The Set Attribute and Get Attribute blocks can set and get, respectively, a maximum of 32 attributes per block instance.

Compatibility Considerations

To set more than 32 attributes, connect two or more Set Attribute blocks. Configure each block to set at most 32 attributes.

To get more than 32 attributes, connect two or more Get Attribute blocks. Configure each block to get at most 32 attributes.

Attribute Propagation Changes

A named attribute now has fixed dimensions and complexity within a discrete-event system. Multiple discrete-event systems within a model can have their own definitions of the same named attribute. In previous releases, attribute value characteristics were consistent across the whole model.

Parameter Handling Change for Routing and Entity Management Blocks

For blocks in the Routing and Entity Management libraries, the Number of entity input ports and Number of entity output ports parameters are no longer restricted to literal values. Instead, the parameter value can be any of the following:

  • Literal value

  • Name of a workspace variable

  • Expression that the block evaluates

Change in Execution Order of Simultaneous Events with Same Priorities

In both current and previous releases, the execution order of simultaneous events with the same priorities has changed.

For example, if the configuration parameter SimEvents > Execution order of your model is configured to Arbitrary for the processing of simultaneous events, and this model has multiple entity generator blocks, each generator generates entities at the start of simulation with the same priority. In previous releases, the entity generator block that generated the first entity might be different.

Compatibility Considerations

To control the execution order of simultaneous events, in the block configuration, change the priority values of the events so that they are all different.

Model Acceleration Changes

Rapid Simulation Support

SimEvents software does not support rapid simulation after you perform the upgrade process using the seupdate function. In this release, performance was greatly enhanced, removing the need for the performance enhancement of rapid simulation.

New Blocks Do Not Support Accelerator Mode

The blocks that support the new paradigm do not support Accelerator Mode.

Compatibility Considerations

If Accelerator Mode is essential to your work with SimEvents models, you should not use the seupdate function to update your SimEvents models and the custom libraries on which those models depend. Instead, you should continue using the older set of SimEvents blocks, from Releases R2009b through R2011a.

Block Library Changes

Updated SimEvents Library

This release provides an updated SimEvents library. After you convert your model with seupdate, you can use blocks from this library after you convert your model. The simeventslib command displays the updated library.

If you want to continue to use your model from a previous release and add blocks to it, use simevents('3').

    Note:   You cannot use blocks from the updated library in a model from a previous release. You also cannot use blocks from a previously released SimEvents library in an R2011b model.

Library Changes

The Event Translation, Probes, and SimEvents User-Defined Functions sublibraries no longer exist. The contents of these sublibraries have either been removed or moved to other sublibraries.

LibrariesCurrent Status
Event TranslationThe blocks in this library have been replaced. See Blocks Being Removed.
ProbesEntity Departure Counter has moved to the Entity Management sublibrary.
SimEvents User-Defined FunctionsAttributes Function has moved to the Attributes sublibrary.

New Blocks

New gateway blocks (Gateway Blocks) and the Event Filter block have been added to the Gateways and the SimEvents Ports and Subsystem libraries, respectively.

Blocks Being Removed

Affected BlocksWhat Happens When You Use the Block?Use This InsteadCompatibility Considerations
  • Discrete Event Subsystem

  • Discrete Event Inport

  • Discrete Event Outport

  • Subsystem Configuration

If the model contains only blocks from earlier versions, the simulation still runs.

If the model contains any SimEvents blocks from this version, the simulation produces errors.

Atomic Subsystem, with inports potentially connected to Event Filter blocksTo learn how to update your legacy models using the seupdate function, see Migrating SimEvents Models.
  • Entity Departure Event to Function-Call Event

  • Entity Departure Event to Function-Call Event Generator

If the model contains only blocks from earlier versions, the simulation still runs.

If the model contains any SimEvents blocks from this version, the simulation produces errors.

Entity Departure Function-Call GeneratorTo learn how to update your legacy models using the seupdate function, see ???.
  • Signal-Based Event to Function-Call Event

  • Signal-Based Event to Function-Call Event Generator

If the model contains only blocks from earlier versions, the simulation still runs.

If the model contains any SimEvents blocks from this version, the simulation produces errors.

Signal-Based Function-Call GeneratorReplace block

Functions Being Removed

Affected FunctionWhat Happens When You Use the Function?Use This InsteadCompatibility Considerations
  • simeventsstartup

Still works. You see a warning message about future removal.

simeventsconfig

Replace existing instances of simeventsstartup with simeventsconfig.

Demos

Updated Demos in the Product

The SimEvents demos have been updated to V4.0. The demos listed in the table have been removed.

NameModel

Anti-Lock Braking System (ABS) Model Using CAN Communications

sedemo_absbrake_can.mdl

Anti-Lock Braking System (ABS) Model with Queuing Delay

sedemo_absbrake_delay.mdl, sedemo_absbrake_nodelay.mdl

Time-Driven and Event-Driven Addition

sedemo_add_num_in_two_queues.mdl

Astable Multivibrator Circuit

sedemo_astable_multivibrator.mdl

Event Priorities

sedemo_event_priorities.mdl

FIFO Buffer: Architectural Model

sedemo_fifo_architectural.mdl

Rate-Based Shared Processor

sedemo_rate_based_proc.mdl

Shared Access Communications Media

sedemo_shared_access_media.mdl

Shared Communication Buffer Management

sedemo_shared_buffer_mgmt.mdl

Tank Filling Station

sedemo_tank_filling_station.mdl

Batch Discrete-Event Simulations Using Rapid Simulation Target

sedemo_rsim_resource_alloc_m

Updated Demos and Examples in the Documentation

SimEvents examples in the documentation have been updated to V4.0.

R2011a

New Features

Changes in Menu of Scope Figure Window

In the figure window that corresponds to any SimEvents scope block, the following menu options no longer appear:

  • File > Page Setup

  • File > Print Setup

Instead, if you select the File > Print Preview menu option, a dialog box opens with similar page and print setup functionality.

R2010b

Bug Fixes

R2010a

New Features, Bug Fixes, Compatibility Considerations

Block-Based Breakpoints in Debugger

With the SimEvents debugger, you can investigate the behavior of particular blocks using block-based breakpoints. After you establish a breakpoint on a block, the debugger suspends the simulation when that block is about to perform certain operations. For details, see these resources:

Block Operations Information in Debugger

These blocks now include their operations in the simulation log:

  • Discrete Event Signal to Workspace

  • Instantaneous Event Counting Scope

  • Signal Scope

  • X-Y Signal Scope

These blocks now appear in the output of the sedb.blklist function and are valid as inputs to the sedb.blkinfo function:

  • Discrete Event Signal to Workspace

  • Discrete Event Subsystem

  • Instantaneous Event Counting Scope

The sedb.blklist function sorts its Command Window output and cell array output by block names instead of by block identifiers.

Compatibility Considerations

If you have code that manipulates or indexes into the output cell array from sedb.blklist, you might need to update the code to reflect new rows or a different sequence of rows.

Changes in Behavior of Pending Entity Signals

The blocks in the following table have an optional pe or #pe signal output port. The signals at these ports provide information about pending entities in the block. The port behaviors are now simpler and more consistent across the various blocks.

BlockHas Optional pe PortHas Optional #pe Port
Event-Based Entity GeneratorYesNo
Infinite ServerYesYes
N-ServerYesYes
Output SwitchYesNo
Single ServerYesNo
Time-Based Entity GeneratorYesNo

In V3.1 (R2010a), a pending entity is an entity that has tried and failed to depart from the block in which the entity resides.

When a block produces a pe output signal, the signal has an update (that is, a sample time hit) whenever there is a change in the set of pending entities that the block stores. The signal value is:

  • 1, if the block stores one or more pending entities

  • 0, if the block does not store any pending entities

When a block produces a #pe output signal, the signal has an update whenever there is a change in the set of pending entities that the block stores. The signal value is the number of pending entities that the block stores.

Compatibility Considerations

If your models use the pe or #pe signal to control simulation behavior, perform computations, or return results, your models might behave differently. The table summarizes the behavioral changes most likely to affect your models. For typical uses of the #pe signal, in which redundant sample time hits with the same value do not matter, the behavioral changes do not change the simulation results.

Affected BlocksChange in Behavior

The pe signal does not have a sample time hit to reflect that an entity departs the first time it tries to depart. Such an entity is not a pending entity because it does not fail to depart.

The same information is true for #pe in blocks that offer this port.

 Example

  • Event-Based Entity Generator

  • Infinite Server

  • N-Server

  • Output Switch

  • Single Server

  • Time-Based Entity Generator

When pe reflects the departure or other removal of a pending entity, the sample time hit occurs after the pending entity is no longer in the block. In earlier versions, when the pending entity is the only pending entity in the block, the sample time hit occurs when the departure or other removal is imminent. The sample time hit occurs at the same simulation time, but in a different sequence compared to other simultaneous events.

 Example

  • Event-Based Entity Generator

  • Time-Based Entity Generator

When you configure the block to produce an error if an entity fails to depart, the error situation does not cause a sample time hit in pe. In this configuration, the block cannot store any pending entities, so there is no storage action to cause a sample time hit in pe.

You see the effect of this change if, after the error occurs, you examine pe in the workspace or in a plot.

  • Infinite Server

  • N-Server

If a pending entity departs and one or more pending entities remain in the block, the pe signal has a single sample time hit of 1. In earlier versions, in this situation, the signal has a sample time hit of 0 followed by a sample time hit of 1.

 Example

Renaming of Parameter to Enable Pending Entity Signal

Blocks that have an optional pe signal output port rename the parameter that you use to enable the port. The name in V3.0 (R2009b) is Status of pending entity departure or Status of pending entity. The new name in V3.1 (R2010a) is Pending entity present in block. The affected blocks are:

Expanded Options for Opening Release Gate

You can configure the Release Gate block to open upon each sample time hit of an input signal. Set the Open gate upon parameter to Sample time hit from port ts.

Blocks in Attributes Library Must Get or Set at Least One Attribute

These blocks no longer support a configuration in which the table in the dialog box is empty:

  • Get Attribute

  • Set Attribute

Parameters and Parameter Values Being Removed

Affected BlockAffected ParameterWhat Happens When You Use the Parameter?Use This InsteadCompatibility Considerations
  • FIFO Queue

  • LIFO Queue

  • Priority Queue

Status of pending entity departure is being removed.

In legacy models in which the parameter is set to On, the corresponding pe signal output port is inactive.

In the library block, the parameter is unavailable.

Number of entities in queueTo update legacy models, set Status of pending entity departure to Off. For more information, see the technique in Determining Whether a Queue Is Nonempty. The technique yields similar, but not identical, information.
  • FIFO Queue

  • LIFO Queue

  • Priority Queue

Capacity must have a positive value.Warns if you set the value to 0.A positive value. Alternatively, remove the block.Remove queue blocks whose capacity is zero.

R2009b

New Features, Bug Fixes

Support for Batch Simulation Using Rapid Simulation Target

SimEvents blocks support code generation using the Rapid Simulation target.

You can now perform these tasks:

  • Accelerating Discrete-Event Simulations Using Rapid Simulation

  • Varying Parameters Between Simulation Runs

  • Sharing Executables for Discrete-Event Simulations

The Batch Discrete-Event Simulations Using Rapid Simulation Target demo illustrates this feature by varying parameters between simulation runs.

This feature requires Real-Time Workshop® software and uses the Rapid Simulation target.

Expanded Options for Resetting Entity Departure Counter

The Entity Departure Counter block offers you more options for resetting the entity count during the simulation. The new options and corresponding values of the Reset counter upon parameter are listed in the table.

OptionValue of "Reset counter upon" Parameter
Reset counter upon each sample time hit of an input signalSample time hit from port ts
Reset counter upon each function callFunction call from port fcn

R2009a

New Features, Bug Fixes, Compatibility Considerations

Debugger Supports Stepping, Breakpoints, and Querying

The new SimEvents debugger lets you use MATLAB functions to suspend a simulation at each step or breakpoint, and query simulation state to assess behavior. The debugger includes these functions:

helpDisplay help for debugger functions
se_getdboptsSimEvents debugger options structure
sedb.bdeleteDelete breakpoints in discrete-event simulation
sedb.blkinfoBlock information in discrete-event simulation
sedb.blklistBlocks and their identifiers in discrete-event simulation
sedb.breakpointsList breakpoints in discrete-event simulation
sedb.contContinue simulation until next breakpoint
sedb.currentopCurrent operation in discrete-event simulation
sedb.detailCustomize debugger display in discrete-event simulation
sedb.disableDisable breakpoints in discrete-event simulation
sedb.enableEnable breakpoints in discrete-event simulation
sedb.eninfoEntity information in discrete-event simulation
sedb.evbreakSet breakpoint for execution or cancelation of event
sedb.evcalEvent calendar of discrete-event simulation
sedb.evinfoEvent information in discrete-event simulation
sedb.gcebName of currently executing block in discrete-event simulation
sedb.gcebidIdentifier of currently executing block in discrete-event simulation
sedb.gcenIdentifier of entity currently undergoing operation
sedb.gcevIdentifier of current event
sedb.quitQuit discrete-event simulation debugging session
sedb.runtoendRun until end of discrete-event simulation
sedb.simtimeCurrent time in discrete-event simulation
sedb.stepSingle step in discrete-event simulation
sedb.tbreakSet timed breakpoint in discrete-event simulation
sedebugDebug discrete-event simulation

For more information, see these resources:

Event Logging Options Removed from Configuration Parameters Dialog Box

The SimEvents pane of the Configuration Parameters dialog box no longer contains event logging options. The behavior of the event logging options in earlier versions is like the behavior of the new debugger.

Compatibility Considerations

The debugger behavior produces slightly different information, with a different format, compared to the information produced by the event logging parameters. The closest approximations to the previous behavior use the detail and runtoend functions of the debugger.

Event Logging Parameter RemovedSimilar Behavior in Debugger
Display events in event calendar
  1. At the MATLAB command prompt, start the debugger on the model called model:

    sedebug(model)
  2. At the sedebug>> prompt, configure the debugger and run the simulation until the end:

    detail none
    detail('ev',1,'cal',1)
    runtoend
Log events when executed
  1. At the MATLAB command prompt, start the debugger on the model called model:

    sedebug(model)
  2. At the sedebug>> prompt, configure the debugger and run the simulation until the end:

    detail none
    detail('ev',1)
    runtoend

The resulting log includes both execution messages and scheduling messages. Execution messages are not indented; scheduling messages are indented.

Log events when scheduled
Log entities advancing from block to block
  1. At the MATLAB command prompt, start the debugger on the model called model:

    sedebug(model)
  2. At the sedebug>> prompt, configure the debugger and run the simulation until the end:

    detail none
    detail('en',1)
    runtoend

The resulting log includes entity advancement messages and other information. Entity advancement messages appear indented.

To approximate the behavior that results from setting multiple parameters for the same model, you can concatenate input arguments in the detail(...) command. For example, detail('ev',1,'en',1) is like logging event scheduling, event execution, and entity operations.

Discrete Event Signal to Workspace Block Clarifies Timing

You can no longer place the Discrete Event Signal to Workspace block in an atomic subsystem. The atomic subsystem executes at time instants that conflict with the time instants at which the event-based block in the subsystem executes. In earlier versions, placing the Discrete Event Signal to Workspace block in an atomic subsystem can produce unexpected results. Function-Call Subsystem and Enabled Subsystem are examples of atomic subsystems.

Compatibility Considerations

If your legacy model includes a Discrete Event Signal to Workspace block in an atomic subsystem, update the model as follows:

  1. Move the Discrete Event Signal to Workspace block outside the atomic subsystem.

  2. Connect the block to an output signal from the subsystem.

R2008b

New Features, Bug Fixes

Attribute Name Incrementing in Set Attribute and Get Attribute Blocks

The Add button in the Set Attribute and Get Attribute blocks adds an attribute named AttributeN where N is a positive integer. In earlier versions, the button always adds an attribute named Attribute1.

Change in Parameter Name of Event-Based Entity Generator Block

The Type of value change parameter in the Event-Based Entity Generator block is now called Type of change in signal value. The new name is consistent with other blocks that have a parameter by that name.

R2008a

New Features, Bug Fixes

Initial Value Block in Signal Management Library

The new Initial Value block is in a new library called Signal Management. This block sets a signal value before the first event occurs.

Also, the Signal Latch block has moved from the Gates library to the new Signal Management library.

Discrete Event Subsystem Supports Complex and Nonscalar Values

In Version 2.2 (R2008a), input signals to the Discrete Event Subsystem block can be real or complex signals of any dimension. In earlier versions, input signals to the block must be real scalars.

Seed Management for Random Number Generators

New functions and diagnostics help you ensure uniqueness of seeds of random number generators and manage sets of seeds in a series of simulation runs. For details, see these sections:

Configuration Parameters for Diagnostics

The Configuration Parameters dialog box has a new SimEvents Diagnostics pane to advise you of race conditions and help you manage seeds of random number generators.

For more information, see SimEvents Diagnostics Pane.

"What's This?" Context-Sensitive Help Available for Simulink Configuration Parameters Dialog

R2008a introduces "What's This?" context-sensitive help for parameters that appear in the Simulink Configuration Parameters dialog. This feature provides quick access to a detailed description of the parameters, saving you the time it would take to find the information in the Help browser.

To use the "What's This?" help, do the following:

  1. Place your cursor over the label of a parameter.

  2. Right-click. A What's This? context menu appears.

    For example, the following figure shows the What's This? context menu appearing after a right-click on the Start time parameter in the Solver pane.

  3. Click What's This? A context-sensitive help window appears showing a description of the parameter.

R2007b

New Features, Bug Fixes, Compatibility Considerations

Attribute Computations Using MATLAB Code

The Attribute Function block lets you conveniently set and modify attributes using MATLAB code. For details, see Writing Functions to Manipulate Attributes.

Simplifying a Model Using the Attribute Function Block

The following figures indicate recommended ways to multiply the absolute value of an attribute by a constant in SimEvents software Version 2.1 (R2007b) and earlier versions. The earlier version is more complicated because of necessary steps to ensure correct timing. By contrast, the Attribute Function block ensures correct timing automatically.

Manipulating Attribute Value Using Attribute Function Block

Manipulating Attribute Value in Earlier Versions

Attributes Support Complex Values

In Version 2.1 (R2007b), attributes can assume complex values, not only real values.

Enhanced Visibility and Logging of Events

In Version 2.1 (R2007b), SimEvents software changes the set of events that appear in event logs:

  • Event logs show a new kind of event, called an entity request event. This event is a notification that an entity input port of a block has become available. To understand the name entity request event, think of the block as requesting an entity from a preceding block. For example, upon becoming empty, a single server requests an entity from a preceding block. A preceding block's response to the notification might result in an entity advancement.

    In earlier versions, entity request events do not appear in event logs.

  • Event logs show a new kind of event, called a storage completion event. This event exists only in an Output Switch block with the Store entity before switching parameter selected. When an entity arrives at the block, the block schedules a storage completion event at the current simulation time. Upon execution of the storage completion event, the block determines whether the entity can advance to a subsequent block.

    In earlier versions, storage completion events do not appear in event logs.

  • Event logs always show the events listed in the following table, regardless of how you set the Resolve simultaneous signal updates according to event priority parameter in the corresponding blocks. This parameter determines whether the event priority is a number you specify in the block dialog box or a system-level category denoted by SYS1.

    Events That Affect Entities and Are Caused By Signal-Based Events

    EventBlock
    Entity generationEvent-Based Entity Generator
    Counter resetEntity Departure Counter
    Gate event (gate opening or gate closing)Enabled Gate
    ReleaseRelease Gate
    Port selectionInput Switch, Output Switch, Path Combiner

    In earlier versions, event logs show these events only if you select Resolve simultaneous signal updates according to event priority in the block dialog box.

Also, event logs and entity logs in Version 2.1 (R2007b) are more readable and contain hyperlinks that highlight the corresponding blocks.

New Demos for Shared-Resource Applications and Advanced Techniques

SimEvents software Version 2.1 (R2007b) introduces these new demonstration models:

Consolidation and Removal of Some Tutorial Demos

The new Server Blocks and Service Time demo replaces these earlier demos:

  • Service Time from Attribute

  • Specifying Service Time in Single Server

  • Specifying Service Time in Infinite Server Block

  • Single Server Block Versus Infinite Server Block

The new Input and Output Switching demo replaces these earlier demos:

  • Input Switching Using Signal

  • Output Switching Using Signal

Changes in Categorization, Titles, and Content of Some Demos

SimEvents demos have been recategorized in the Help browser. Some demos have changed their titles or content.

Title in Version 2.1 (R2007b)Title in Earlier Versions
Task Sharing with Two Levels of Priority and PreemptionPreemptive Operating System with Two Levels of Priority
Multitasking with Dependent TasksMultitasking Model with Dependent Tasks
Operating System with Prioritized Task ExecutionOperating System Model with Prioritized Task Execution
Entity Combiner for Assembling Components (with simpler design using the Entity Combiner and Attribute Function blocks)Aggregation: Assembling a Vehicle Chassis

Also, the G/G/1 Queuing System and Little's Law demo has a simpler design using the Attribute Function and Embedded MATLAB Function blocks.

Subsystem Connection Port for Entity Paths

The Conn block represents an entity input port or entity output port in a virtual subsystem. The model window's Edit > Create Subsystem menu option automatically creates connection ports. Copying the Conn block from its library is a convenient way to add more entity ports to an existing subsystem.

Configuration Parameters to Control Livelock

The SimEvents pane of the Configuration Parameters dialog box offers new parameters for setting thresholds related to livelock. Also, the Execution order of simultaneous events parameter has been renamed Execution order.

New ParameterDescription
Maximum events per blockLimit the number of entity generation, service completion, subsystem execution, and function-call events that each SimEvents block performs at each fixed time instant.
Maximum events per modelLimit the total number of events scheduled via the event calendar at each fixed time instant.

Processing Events Via the Event Calendar Instead of Immediately

In Version 2.1 (R2007b), SimEvents software changes its processing of each event in the next table when you do not select Resolve simultaneous signal updates according to event priority in the corresponding block. In this case, the event has a system-level event priority denoted by SYS1, and the application processes the event via the event calendar. Using the event calendar decouples the scheduling and the execution of events. Event Sequencing describes how the application processes multiple simultaneous events.

Events That Affect Entities and Are Caused By Signal-Based Events

EventBlock
Entity generationEvent-Based Entity Generator
Counter resetEntity Departure Counter
Gate event (gate opening or gate closing)Enabled Gate
ReleaseRelease Gate
Port selectionInput Switch, Output Switch, Path Combiner

Also, each entity request event has a system-level priority denoted by SYS2, and the application processes the event via the event calendar.

In earlier versions, the application applies "immediate" processing for entity requests by storage blocks, as well as for events in the table when you do not select the Resolve simultaneous signal updates according to event priority parameter in the corresponding block.

For details about supported events and the processing of simultaneous events, see Working with Events and Managing Simultaneous Events.

Compatibility Considerations

Most models are unaffected by the change in event processing. However, some models might behave differently, because events processed immediately in earlier versions are deferred to the event calendar in SimEvents software Version 2.1 (R2007b). Models that behave differently tend to involve cycles in simulation processing and cascades of simultaneous events (for example, an event has multiple consequences that occur at time T, each of which has further consequences also at time T).

Example Showing Change in Behavior

The model below attempts to simultaneously advance one entity from each queue, whenever both queues are nonempty.

Suppose that the top queue contains one entity and an entity arrives at the previously empty bottom queue. Assuming that no block in the model has its Resolve simultaneous signal updates according to event priority parameter selected, the entity arrival has the following cascade of consequences:

  1. The bottom queue updates its #n output signal to 1.

  2. The discrete event subsystem evaluates the condition (A AND B) and returns a value of 1. The previous value of this signal was 0.

  3. Each of the two Release Gate blocks detects a value-change event at its vc signal input port. In SimEvents software Version 2.1 (R2007b), each of the two gates schedules a release event on the event calendar.

  4. One gate opens, which has these consequences:

    1. An entity advances from the corresponding queue to the sink.

    2. The corresponding queue updates its #n output signal to 0.

    3. The discrete event subsystem reevaluates the condition (A AND B) and returns a value of 0.

  5. In Version 2.1 (R2007b), the other gate opens, which has these consequences:

    1. An entity advances from the corresponding queue to the sink.

    2. The corresponding queue updates its #n output signal to 0.

    3. The discrete event subsystem reevaluates the condition (A AND B) and returns a value of 0.

In earlier versions, the gates do not schedule release events on the event calendar if the corresponding Resolve simultaneous signal updates according to event priority parameter is not selected. As a result, step 4c negates the value-change event at the other gate and step 5 does not occur. This example involves cycles in simulation processing, because an event at the gate affects the value of the #n signal of a preceding block. This example involves cascades of simultaneous events, because the new value of 1 for the condition (A AND B) causes two release events, each of which causes the condition (A AND B) to assume the value 0.

Enhanced Support for Multiple Simultaneous Transitions in Switches and Gate

The blocks in this table model the effects of all transitions in their input signals, even if multiple transitions occur simultaneously.

BlockInput Signal
Enabled Gateen
Input Switchp
Output Switchp
Path Combinerp

In earlier versions of SimEvents software, selecting the Resolve simultaneous signal updates according to event priority option causes the blocks to model only the last transition at a given value of the simulation clock.

Compatibility Considerations

The behavior of some simulations changes depending on whether the application models intermediate transitions in an en or p input signal in the blocks in the table above.

Example Showing Change in Behavior

In the model below, the en signal transitions from 0 to 1 and then from 1 to 0 in the same time instant. Earlier versions model only the latter transition, so the gate does not open. Version 2.1 (R2007b) models both transitions, so the gate opens and then closes in the same time instant.

Change in Indexing in Attribute Scope Block

When you set the X value from parameter to Index in the Attribute Scope block, it creates a plot that reflects 1-based indexing. That is, the first entity corresponds to a data point whose value on the horizontal axis is 1. In earlier versions, the plot reflects 0-based indexing.

R2007a

New Features, Bug Fixes, Compatibility Considerations

Attributes Support Multidimensional Values

Version 2.0 (R2007a) introduces new versions of the Get Attribute and Set Attribute blocks in a new Attributes library. The new blocks offer these enhancements compared to the earlier versions:

  • Attributes can assume values that are vectors, matrices, or multidimensional arrays with up to 32 dimensions, not just scalars. This enhancement facilitates modeling dense payloads via attributes.

  • Each instance of a Set Attribute block can assign an arbitrary number of attributes, and each instance of a Get Attribute block can retrieve an arbitrary number of attributes.

  • The dialog boxes use a grid on a single tab, making it easier for you to see the entire list of attributes that a block sets or gets.

Compatibility Considerations

If your legacy models contain Get Attribute or Set Attribute blocks from the earlier library, those blocks continue to work in Version 2.0 (R2007a). However, the blocks are considered obsolete, as described in Obsolete Blocks.

Combining and Splitting Entities

The new Entity Combiner block lets you combine entities, analogous to combining components to create a larger whole. The block provides options for managing information (attributes and timers) associated with the component entities, so you can think of the operation as bundling the information that entities carry with them.

You can configure the Entity Combiner block to make the combining operation reversible via the Entity Splitter block.

The Entity Combiner and Entity Splitter blocks reside in the new Entity Management library.

Timeout Feature Establishes Entity Time Limits

You can model point-to-point timing constraints by limiting the amount of time an entity spends during the simulation on designated entity paths. Exceeding the limit causes the entity to depart immediately from the storage block where it resides, such as a queue, when the clock reaches the time limit. To learn how to use this feature, see Forcing Departures Using Timeouts.

The timeout feature involves new blocks, as well as new parameters in existing blocks.

New BlockPurpose
Schedule TimeoutSchedule timeout event for each entity
Cancel TimeoutCancel timeout event for each entity

New Parameter of Existing BlocksPurpose
Enable TO port for timed-out entities on Timeout tabProvide a TO entity output port through which an entity departs upon timing out
Number of entities timed out on Statistics tabOutput a signal, #to, that indicates the number of entities that have timed out from the block since the start of the simulation

Compatibility Considerations

If you save a model containing a queue, server, or Output Switch block using V2.0 (R2007a), then opening the model in V1.2 (R2006b) produces warnings like these:

Warning: In instantiating linked block 'mysys/FIFO Queue' :
FIFO Queue block (mask) does not have a parameter named
'EnableTOPort'.
Warning: In instantiating linked block 'mysys/FIFO Queue' :
FIFO Queue block (mask) does not have a parameter named
'StatNumberTimedout'.

Saving the model in the earlier version prevents the warnings from reappearing, but causes the block to omit timeout-related ports and behavior if you later open the model in V2.0 (R2007a).

New Demos for Video Processing, Communications, and Architecture Modeling

Version 2.0 (R2007a) introduces these new demonstration models:

Change in ARQ Demo

The Selective-Repeat Automatic Repeat Request demo reverses the interpretation of the CRC check compared to V1.2 (R2006b). The interpretation now matches that of the similar Go-Back-N Automatic Repeat Request demo. In V2.0 (R2007a), both demos use a CRC check value of 1 to correspond to an ACK message.

Output Switch Block Options for Storage and Initial Condition

The Output Switch block offers enhancements that can prevent the need for additional blocks to set initial conditions or to prevent latency. The new parameters apply to signal-based switching and are available only when you set Switching criterion to From signal port p. The new parameters are in the table below. For details, see Output Switching Based on a Signal and the block's reference page.

New ParameterPurpose
Specify initial port selectionDetermine whether the block uses an initial port selection from the dialog box.
Initial port selectionThe entity output port that the block selects when the simulation begins. The block uses this value instead of the p signal until the signal has its first sample time hit.
Store entity before switchingIf you select this option, the block can store one entity at a time. Furthermore, the block decouples its arrival and departure processing to give other blocks in the simulation an opportunity to update the p signal if appropriate. If you do not select this option, the block processes an arrival and departure as an atomic operation and assumes that the p signal is already up to date at the given time.
Status of pending entity on Statistics tabOutput a signal, pe, that indicates when the block stores an entity after trying and failing to output it. A value of 0 indicates when the storage location is empty.

For other changes in this release that affect parameters of the Output Switch block, see Timeout Feature Establishes Entity Time Limits and Changes in Names of Parameters Related to Event Priorities.

Compatibility Considerations

In some cases, the block enhancements let you optionally simplify models that you do not need to share with users of earlier versions:

  • If your model precedes an Output Switch block with a Signal Latch block to create an initial condition for the p signal, and if the p signal does not branch to become an input for another block, then you can remove the Signal Latch block and instead use the new Specify initial port selection option in the switch block.

  • If your model precedes an Output Switch block with a Single Server block whose Service time parameter is zero and whose sole purpose was to ensure an up-to-date p signal, then you can remove the Single Server block and instead use the new Store entity before switching option in the switch block.

If you save a model containing an Output Switch block using V2.0 (R2007a), then opening the model in V1.2 (R2006b) produces warnings like these:

Warning: In instantiating linked block 'mysys/Output Switch' :
Output Switch block (mask) does not have a parameter named
'InitialConditionsOpt'.
Warning: In instantiating linked block 'mysys/Output Switch' :
Output Switch block (mask) does not have a parameter named
'InitialConditions'.
Warning: In instantiating linked block 'mysys/Output Switch' :
Output Switch block (mask) does not have a parameter named
'EntityBufferOpt'.
Warning: In instantiating linked block 'mysys/Output Switch' :
Output Switch block (mask) does not have a parameter named
'StatPendingEntity'.

Saving the model in the earlier version prevents the warnings from reappearing, but causes the block to omit ports and behavior related to the V2.0 (R2007a) enhancements if you later open the model in V2.0 (R2007a).

Entity Departure Counter Block Can Create Attribute

If you configure the Entity Departure Counter block to write the count to an attribute, then you can select the new Create attribute if not present parameter to have the block create the attribute if it does not already exist. The block then sets the value of the attribute according to the entity count.

In earlier versions, the block sets the value of the attribute but does not create it.

Changes in Names of Parameters Related to Event Priorities

Parameters related to optional priorities of events have been renamed to be more suggestive of how the option works. The name Resolve simultaneous signal updates according to event priority replaces names that start with Specify event priority. In a subset of affected blocks, the name Event priority replaces similar names. For more information about what the parameters mean, see Choosing How to Resolve Simultaneous Signal Updates.

The table below itemizes the blocks and parameters that have changed.

BlockParameter Name in V1.2 (R2006b)Parameter Name in V2.0 (R2007a)
Discrete Event InportSpecify event priority for executing subsystemResolve simultaneous signal updates according to event priority
Subsystem execution event priorityEvent priority
Enabled GateSpecify event priority for gate opening and closingResolve simultaneous signal updates according to event priority
Entity Departure CounterSpecify event priority for counter resetResolve simultaneous signal updates according to event priority
Event-Based Entity GeneratorSpecify event priority for entity generationResolve simultaneous signal updates according to event priority
Generation event priorityEvent priority
Input SwitchSpecify event priority for port selectionResolve simultaneous signal updates according to event priority
Output SwitchSpecify event priority for port selectionResolve simultaneous signal updates according to event priority
Path CombinerSpecify event priority for port precedence selectionResolve simultaneous signal updates according to event priority
Release GateSpecify event priority for gate openingResolve simultaneous signal updates according to event priority
Signal LatchSpecify event priority for writing to memoryResolve simultaneous signal updates according to event priority on Write tab
Specify event priority for reading from memoryResolve simultaneous signal updates according to event priority on Read tab
Signal-Based Event to Function-Call EventSpecify event priority for function-call generationResolve simultaneous signal updates according to event priority
Function-call event priorityEvent priority
Signal-Based Function-Call Event GeneratorSpecify event priority for function-call generationResolve simultaneous signal updates according to event priority
Function-call event priorityEvent priority

This change merely renames parameters and does not change the behavior of affected blocks.

Change in Default Entity Type of Entity Generators

The default value of Entity type in the Time-Based Entity Generator and Event-Based Entity Generator block is Blank. In earlier versions, the default value is Standard. This change in default value does not affect blocks in a saved model but only affects new instances of the block that you copy from the library to a model.

Obsolete Blocks

The table below indicates blocks that are obsolete as of the current version or that are planned to be removed in a future version.

Obsolete BlockRemoved from VersionReplacement
Get Attribute block from simeventsattributes1 libraryFuture versionGet Attribute block from simeventsattributes2 library
Set Attribute block from simeventsattributes1 libraryFuture versionSet Attribute block from simeventsattributes2 library

R2006b

New Features, Bug Fixes, Compatibility Considerations

Event-Based Sequence Generator Block

The new Event-Based Sequence block provides data to an event-driven process by producing a scalar event-based output signal whose values come from a vector. The block selects the next value from the vector upon each notification from a port of a subsequent block. For example, if you connect the Event-Based Sequence block to the t input port of a Single Server block, the values in the vector become the service times for the entities arriving at the server. You provide the values in the vector, but do not need to know in advance when the entities arrive at the server.

Event Translation Block Supports Delay from a Signal

The Signal-Based Event to Function-Call Event block can delay its generation of a function call by an amount of time that you specify using either an input signal or the Function-call time delay parameter. In V1.1 (R2006a), the block lets you specify the delay amount using the parameter, but not an input signal.

To access the new feature, select Specify event priority for function-call generation (or, in V2.0 (R2007a), select Resolve simultaneous signal updates according to event priority). Then set the new Function-call delay from parameter to Signal port t, as shown. Then connect a nonnegative-valued signal to the t signal input port that appears on the block.

Compatibility Considerations

If you save a model containing the Signal-Based Event to Function-Call Event or Discrete Event Subsystem block using V1.2 (R2006b), then opening the model in V1.1 (R2006a) produces warnings like these:

Warning: In instantiating linked block 'mysys/Signal-Based
Event to Function-Call Event' : Signal-Based Event to Function-
Call Event block (mask) does not have a parameter named
'FunctionCallDelayFrom'.

Saving the model in the earlier version prevents the warnings from reappearing, but causes the Signal-Based Event to Function-Call Event block to omit the t input port if you later open the model in V1.2 (R2006b).

Routing Blocks Support Unlimited Entity Ports

The Number of entity input ports parameter of the Input Switch and Path Combiner blocks can be any positive integer. The Number of entity output ports parameter of the Output Switch and Replicate blocks also can be any positive integer. In V1.1 (R2006a), these parameters can assume only the values 1, 2, 3, and 4.

Compatibility Considerations

If you save a model in which one of the blocks listed above has more than four entity input ports or more than four entity output ports, then the model will not work in V1.1 (R2006a).

Initial Outputs of SimEvents Blocks

All SimEvents blocks now have well-defined initial values for any numerical output signals they produce.

The initial value of an output signal of a SimEvents block is in effect from the start of the simulation until the block updates the output signal for the first time during the simulation. For example, if an N-Server block is configured to produce a #n output signal representing the number of entities in the server, then #n has a well-defined initial value of 0 at the start of the simulation. The initial value persists until the first arrival of an entity at the N-Server block, which could occur well after the start of the simulation, if at all.

The block reference pages indicate the initial values of the block output signals.

Compatibility Considerations

If you connect the Signal Latch block to a ts, tr, or vc signal input port of a SimEvents block, the input port might detect an event at the start of the simulation in V1.1 (R2006a) that no longer occurs in V1.2 (R2006b). This is because the Signal Latch block assumes its initial condition in a true initialization stage in V1.2 (R2006b) rather than slightly after the simulation start in V1.1 (R2006a). If your model relies on an event at the start of the simulation (to invoke a discrete event subsystem or generate an event or an entity, for example), then you might see a change in simulation behavior between the two versions.

For example, the model below uses a Discrete Event Subsystem block to compute a signal that indicates whether a gate is open or closed.

Subsystem Invoked at Simulation Start in V1.1 (R2006a), but Not V1.2 (R2006b)

In V1.1 (R2006a), the Signal Latch block's output signal has a sample time hit at the start of the simulation. This sample time hit invokes the subsystem, which initializes the gate's en input signal to 1. As a result, the gate is open at the start of the simulation. In V1.2 (R2006b), the Signal Latch block does not have a sample time hit at the start of the simulation, so the initial condition of the subsystem's outport determines the initial condition of the gate's en input signal. As a result, the gate is closed at the start of the simulation.

An alternative approach that works in both versions is to move the Signal Latch block so that it follows the Discrete Event Subsystem block. The Signal Latch block directly provides the gate's initial condition.

Correct Gate Initialization in Both V1.1 (R2006a) and V1.2 (R2006b)

History Options and Other Changes in Scope Blocks

The following blocks include new Store data when scope is closed and Limit data points to parameters on the new Data History tab of the dialog box:

The parameters determine how much data the blocks cache, letting you balance data visibility with simulation efficiency. Caching data lets you view it later, even if the scope is closed during part or all of the simulation. Caching less or no data accelerates the simulation and uses less memory. In V1.1 (R2006a), if you have the scope closed for the first T seconds of simulation and then open the scope, you can view only the data for t>T.

Other Changes in Scope Blocks

Version 1.2 (R2006b) changes some aspects of the way you interact with the scope blocks:

  • A Pan toolbar button lets you move your view of a plot.

  • A Parameters toolbar button opens the block dialog box.

  • Double-clicking on the block opens the plot if it is not already open. In V1.1 (R2006a), double-clicking on the block opens the block dialog box. To open the block dialog box in V1.2 (R2006b), click the Parameters toolbar button on the plot.

  • The autoscale feature no longer changes the initial axis limits that you specify in the block dialog box. A new Save axes limits menu option lets you update the initial axis limits to match the plot's current limits. The current limits might differ from their initial values due to stretching, shifting, panning, zooming, or autoscaling operations that occurred since the initial values were last set.

  • The former Open at start of simulation parameter is now called Open scope at start of simulation and has moved from the Figure tab of the dialog box to the Plotting tab.

The scope blocks also plot initial conditions without a plotting marker. In V1.1 (R2006a), initial conditions typically do not appear in plots.

Finally, the scope blocks run significantly faster in V1.2 (R2006b).

Compatibility Considerations

If your legacy models contain scope blocks that plot more than 1000 points, then the default values of the new Store data when scope is closed and Limit data points to parameters cause the scope to retain only the last 1000 points. To plot all points, set Store data when scope is closed to Unlimited.

If you save a model containing a scope block using V1.2 (R2006b), then opening the model in an earlier version produces warnings about the parameters that are not in the earlier block. For example,

Warning: In instantiating linked block 'mysys/Attribute
Scope' : Attribute Scope block (mask) does not have a parameter
named 'DataStoreOption'.
Warning: In instantiating linked block 'mysys/Attribute
Scope' : Attribute Scope block (mask) does not have a parameter
named 'DataPointsLimit'.

Saving the model in the earlier version prevents the warnings from reappearing, but also causes the block to use default values for the new parameters if you later open the model in V1.2 (R2006b).

Parameters for Lognormal Distribution

The Event-Based Random Number block produces random numbers from a lognormal distribution when you set the Distribution parameter to Lognormal. Different texts use different parameterizations of the lognormal distribution. V1.2 (R2006b) renames some parameters in this block to clarify the relationship between a lognormal random variable X and the normal random variable log(X).

V1.1 (R2006a) Parameter NameV1.2 (R2006b) Parameter Name
ScaleMu
ShapeSigma

Compatibility Considerations

The block behaves the same in V1.1 (R2006a) and V1.2 (R2006b) because the change merely renames parameters. However, the parameter names in V1.2 (R2006b) more accurately reflect the block's behavior.

SimEvents Blocks Compatible with Accelerator Mode

All SimEvents blocks are compatible with accelerator mode. Version 1.1 (R2006a) does not support simulating models in accelerator mode if the models contain the Event-Based Random Number block.

Livelock Detection

SimEvents software can detect livelock during a simulation. When it detects livelock, it halts the simulation with an error message that indicates too many simultaneous events. In V1.1 (R2006a), livelock can potentially cause MATLAB software to crash.

For details, see Livelock Prevention.

Compatibility Considerations

It is possible for the application to consider a situation to be livelock when it is actually a large but finite loop. Such simulations might work in V1.1 (R2006a) but not in V1.2 (R2006b).

R2006a

New Features, Bug Fixes, Compatibility Considerations

Replicate Block Supports Partial Replication

The Replicate block supports partial replication and offers more flexibility when you choose complete replication. New parameters in the block's dialog box are in the table below.

ParameterDescription
Replicate entity whenLets you choose whether the block accepts arriving entities for replication only when all entity output ports are not blocked or whenever at least one entity output port is not blocked. The first option is the default.
If an output port becomes blocked during replicationDetermines how the block responds if a departure through one entity output port causes another entity output port to become blocked.
Number of entities departedToggles the optional output signal #d, representing the number of departed entities.

Compatibility Considerations

By default in V1.1 (R2006a), when a departure through one entity output port causes another entity output port to become blocked, the result is a discarded entity with no error or warning message. If this phenomenon occurs in your legacy models, then the result in V1.0 (R14SP3+) might be an error message or incorrect behavior. If you want to learn when this phenomenon occurs in your legacy models that you simulate using V1.1 (R2006a), then set If an output port becomes blocked during replication to either Warn and discard entity, or Error.

The default values of the other new parameters added in V1.1 (R2006a) are consistent with the block's behavior in V1.0 (R14SP3+), so legacy models need no changes to accommodate these new features.

If you save a model containing the Replicate block using V1.1 (R2006a), then opening the model in V1.0 (R14SP3+) produces warnings about the parameters that are not in the V1.0 block. For example,

Warning: In instantiating linked block 'mysys/Replicate' :
  Replicate block (mask) does not have a parameter named
  'ReplicateEntityWhen'.
Warning: In instantiating linked block 'mysys/Replicate' :
  Replicate block (mask) does not have a parameter named
  'ActionUponBlocking'.
Warning: In instantiating linked block 'mysys/Replicate' :
  Replicate block (mask) does not have a parameter named
  'StatNumberDeparted'.

Also, simulating that model under V1.0 causes the block to exhibit its V1.0 behavior, which is to omit a #d output signal and to replicate the arriving entity only when all entity output ports are not blocked. Saving the model in V1.0 prevents the warnings from reappearing in V1.0 but also causes the block to exhibit its V1.0 behavior if you later open the model in V1.1.

R14SP3+

New Features

Introduction to SimEvents

SimEvents software extends Simulink software with tools for modeling and simulating discrete-event systems using queues and servers. With SimEvents software you can create a discrete-event simulation model to simulate the passing of entities through a network of queues, servers, gates, and switches based on events. The software provides an integrated environment for modeling hybrid dynamic systems containing continuous-time, discrete-time, and discrete-event components.

A key concept that SimEvents software adds to the Simulink environment is that of entities, which are discrete items of interest in a discrete-event simulation. For example, entities could represent messages to be communicated or parts to be assembled. Entities can carry data in one or more scalar structures called attributes. For example, attributes could represent destinations of messages or dimensions of parts.

The libraries in SimEvents software contain blocks that can

  • Create entities

  • Store entities in a queue

  • Serve or delay entities

  • Forbid or allow entities to depart, depending on specified criteria

  • Manipulate the paths on which entities travel

  • Attach data or timers to entities

  • Create plots using data from entities or statistics gathered during simulation

  • Manipulate or generate discrete events that can affect the behavior of blocks and entities

  • Control the simulation timing in situations where event-driven behavior and time-driven behavior interact

Was this topic helpful?