| Version 2.1 (R2007b) SimEvents® Software Release Notes | |
This table summarizes what's new in Version 2.1 (R2007b):
| New Features and Changes | Version Compatibility Considerations | Fixed Bugs and Known Problems | Related Documentation at Web Site |
|---|---|---|---|
| Yes Details below | Yes—Details labeled as Compatibility Considerations, below. See also Summary. | Bug Reports Includes fixes | No |
New features and changes introduced in this version are
New Demos for Shared-Resource Applications and Advanced Techniques
Processing Events Via the Event Calendar Instead of Immediately
Enhanced Support for Multiple Simultaneous Transitions in Switches and Gate
The Attribute Function block lets you conveniently set and modify attributes using Embedded MATLAB™ code. For details, see Writing Functions to Manipulate Attributes.
The figures below 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
In Version 2.1 (R2007b), attributes can assume complex values, not just real values.
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. It is called an entity request event because you can 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 table below, 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's dialog box or a system-level category denoted by SYS1.
Events That Affect Entities and Are Caused By Signal-Based Events
| Event | Block |
|---|---|
| Entity generation | Event-Based Entity Generator |
| Counter reset | Entity Departure Counter |
| Gate event (gate opening or gate closing) | Enabled Gate |
| Release | Release Gate |
| Port selection | Input Switch, Output Switch, Path Combiner |
In earlier versions, event logs show these events only if you select the Resolve simultaneous signal updates according to event priority parameter in the block's dialog box.
Also, event logs and entity logs in Version 2.1 (R2007b) are more readable and contain hyperlinks that highlight the corresponding blocks.
For details about event logs, see Viewing the Event Calendar. For details about entity logs, see Viewing Entity Locations.
SimEvents software Version 2.1 (R2007b) introduces these new demonstration models:
Advanced Technique Demos
Application 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
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 Preemption | Preemptive Operating System with Two Levels of Priority |
| Multitasking with Dependent Tasks | Multitasking Model with Dependent Tasks |
| Operating System with Prioritized Task Execution | Operating 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.
The Conn block represents an entity input port or entity output port in a virtual subsystem. While 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.
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 Parameter | Description |
|---|---|
| Maximum events per block | Limit 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 model | Limit the total number of events scheduled via the event calendar at each fixed time instant. |
For more information, see Livelock Prevention or the configuration parameter descriptions.
In Version 2.1 (R2007b), SimEvents software changes its processing of each event in the next table when you do not select the Resolve simultaneous signal updates according to event priority parameter 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
| Event | Block |
|---|---|
| Entity generation | Event-Based Entity Generator |
| Counter reset | Entity Departure Counter |
| Gate event (gate opening or gate closing) | Enabled Gate |
| Release | Release Gate |
| Port selection | Input 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.
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:
The bottom queue updates its #n output signal to 1.
The discrete event subsystem evaluates the condition (A AND B) and returns a value of 1. The previous value of this signal was 0.
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.
One gate opens, which has these consequences:
An entity advances from the corresponding queue to the sink.
The corresponding queue updates its #n output signal to 0.
The discrete event subsystem reevaluates the condition (A AND B) and returns a value of 0.
In Version 2.1 (R2007b), the other gate opens, which has these consequences:
An entity advances from the corresponding queue to the sink.
The corresponding queue updates its #n output signal to 0.
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.
The blocks in this table model the effects of all transitions in their input signals, even if multiple transitions occur simultaneously.
| Block | Input Signal |
|---|---|
| Enabled Gate | en |
| Input Switch | p |
| Output Switch | p |
| Path Combiner | p |
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.
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.
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.
| Version 2.2 (R2008a) SimEvents® Software | Version 2.0 (R2007a) SimEvents® Software | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |