This chapters provides general information related to simulation in SDT and describes the actions you perform when simulating an SDL system.
For a reference to the simulator user interface, see The SDT Simulator.
In order to generate a simulator, the C Code Generator is used. The simulators generated using the C Code Generator consist of the following components:
Additional tools support graphical trace when executing a simulator:
Figure 446 : Structure of a running simulator
|
|
The application is a representation in C code of the implementation of the SDL system. Having generated the application (that is, translated the SDL system into C code), the SDT C Code Generator generates a makefile which contains instructions about how to compile and link the application together with the appropriate runtime library. A number of libraries are provided, which allow you to generate an application with the desired behavior. For instance, it is possible to have multiple simulators communicate with each other or communicate with an external application, provided that application has the facility to communicate through the SDT integration mechanism, the Postmaster.
An executing simulation program contains a number of data objects that represent certain SDL objects in the system that is being simulated. Process instances, signal instances (signals that are waiting in the input port of a process instance), and timer instances (timers that are set, but that have not output their corresponding signal instance) are all examples of such objects. These objects, together with the process instance env:1, which represents the environment of the system, and the monitor system, constitute the simulation program (see Figure 446).
The process instances in the simulated system will execute transitions that consist of actions like tasks, decisions, outputs, procedure calls, and so on, according to the rules of SDL. It is assumed that a transition takes no time and that a signal instance is immediately placed in the input port of the receiver when an output operation occurs.
The function of the environment process instance, env:1, is to be a receiver of signal instances sent from the system to the environment of the system. The input port of env:1 will always hold the last 20 signals sent to the environment.
When generating a simulating application, a monitor system is included, the function of which is to allow the interaction between the application and the user via a command-line user interface. The monitor system provides a functionality similar to high-level language debuggers, in which you can, for instance:
The interactive monitor is the interface between the user and the simulated system. The monitor can be seen as an ordinary process instance, which, when executing a transition, accepts commands from the user.
One group of monitor commands terminate the current transition of the monitor, allow one or several other process instances to execute their transitions, and then start a new transition by the monitor.
A graphical user interface to the monitor system of a simulator, known as the Simulator UI, is also provided. It is a window-based tool which facilitates the use of the monitor system. It contains graphical components, such as buttons, menus, and scrollable lists, which make it easier to run the simulator in an intuitive way. Also, it is designed to minimize the required amount of user interaction.
|
Note: Running the graphical user interface requires that the Cbasic code generator is present in your SDT configuration. |
When running the Simulator UI, the user has the option to take advantage of the graphical features which are provided, or to enter commands in a command line fashion in the same way as the textual interface.
There are two ways to generate and start a simulator:
In the following, the more complex way will be described first, to give a full understanding of the process. The quick way is described in Quick Start of a Simulator.
A Simulator for an SDL system, or a part of an SDL system, consists of the C code generated by the SDT C Code Generator together with a precompiled run-time kernel. To start a Simulator, it is thus necessary to first generate an executable simulator. This is performed in the Organizer.
To generate an executable simulator:
<system>_xxx.sct (the _xxx suffix is platform specific). <system>_xxx.exe (the _xxx suffix is kernel and compiler specific). An executable simulator can be run in two different modes; graphical mode and stand-alone mode (textual mode).
In graphical mode, the Simulator takes advantage of SDT's graphical user interface and integration mechanism. A separate graphical user interface, the Simulator UI, is started, giving access to the monitor system through the use of menus, command buttons, etc.
To start a simulator in graphical mode:
A welcome message is printed in the text area of the Simulator UI. The monitor system is now ready to accept commands. Please see Supplying Values of External Synonyms for some additional information that may affect the start-up.
In stand-alone mode, the Simulator uses the input and output devices currently defined on your computer, which provide a textual, command-line based user interface. A very limited graphical support is provided when running the Simulator in this mode.
To start a simulator in stand-alone mode, the generated simulator is executed directly from the OS prompt, e.g.
csh% ./system_sma.sct
A welcome message is printed on the terminal:
Welcome to SDT SIMULATOR. Simulating system <system> Command :
The monitor system is now ready to accept commands. Please see Supplying Values of External Synonyms for some additional information that may affect the start-up.
A simulator can also be generated and automatically started in graphical mode in one single step.
To quick start a simulator, click the Simulate quick button in the Organizer's tool bar. The following things happen:
An executing simulator can be restarted from the beginning to reset its state completely:
The SDL system for the simulator may contain external synonyms that do not have a corresponding macro definition (see External Synonyms). In that case, you will be asked to supply the values of these synonyms, either by selecting a file with synonym definitions, or by entering each synonym value from the keyboard.
In stand-alone mode, the following prompt appears:
External synonym file :
Enter the name of a file containing synonym definitions, or press <Return> to be prompted for each synonym value.
In graphical mode, a file selection dialog is opened. Either select a file (*.syn) containing synonym definitions, or press Cancel to be prompted for each value in a separate dialog. In this dialog, the name and type of the synonym is shown together with an input text field. You can now do the following:
If a synonym file is selected in the file selection dialog, this file is also used when the simulation is restarted. (If you by any chance want to use another synonym file you have to start a new Simulator UI.)
If you set the environment variable SDTEXTSYNFILE to a file before starting SDT this file will automatically be used. If SDTEXTSYNFILE is set to "[[" all synonyms are given "null" values.
The syntax of a synonym file is described in Reading Values at Program Start up.
When a simulator is started, the static process instances in the system are created, but their initial transitions are not executed.
If a file called siminit.com exists in the current directory an implicit Include-File command will be done on this file at startup.
Whenever the interactive monitor system becomes active, commands are accepted from the user. When running the simulator in stand-alone mode, commands can only be entered textually from a command prompt. When running the simulator in graphical mode, commands may be issued both textually and through the use of menus and buttons.
The simulator's monitor system becomes active when the simulator is started, when the execution has reached a stop condition or a breakpoint, when the system is completely idle, when a semantic error occurs, or when the execution is manually stopped.
These conditions are listed in greater detail in Activating the Monitor.
The commands to the monitor system consist of a command name and possibly one or more parameters to the command, separated by spaces or carriage return. The following general rules apply:
List-Ready-Queue list-ready l-r-q
To get a simple list of all possible command names, enter a `?' at the command prompt. A command can then be entered after the list.
To get a list of all commands, grouped into different categories, use the command Help without parameters.
To get a list of all possible commands starting with a certain string, enter the string and hit <Return>. Unless the string was a complete command, all command names starting with the entered string are listed. The following example shows how to list all output commands:
Command : out Command was ambiguous, it might be an abbreviation of: Output-To Output-Via Output-None Output-Internal
To get short help on a specific command, use the Help command and specify the command in question as a parameter, e.g.
Command : help help Help <Optional command name> Issuing the help command will print all the available commands. If help is entered with a command name, this command will be explained.
To get a list of possible parameter values, enter a `?' on the command line or when prompted for a missing parameter.
To specify a default value for a parameter, enter a `-' on the command line or when prompted for a missing parameter.
If a default value exists for a parameter, you may also hit <Return> when prompted for the parameter to accept the default value. However, if no default value exists, this will list the possible values and prompt for the parameter again.
The graphical Simulator UI is illustrated in the figure below:
|
|
All input and output texts to and from the simulator monitor is displayed in the text area to the right.
To enter monitor commands textually:
Monitor commands entered textually are saved in a history list. To re-execute a command in the history list:
<Up> and <Down> to display the commands that have been entered earlier. <Return> on the command line to re-execute the displayed command. You may edit the command before executing it.The preferred way to issue monitor commands is by using the command buttons in the left area of the Simulator UI, or by using menu choices in the menu bar. Each button or menu choice correspond to a certain monitor command. The buttons are grouped into modules, corresponding to different categories and uses of the commands. The groups are similar to those listed when using the Help command in the textual interface.
To "preview" the command associated with a button or menu choice, without executing it:
To execute a command, simply click on a button.
Parameters to monitor commands are prompted for in dialogs (unless they have been specified on the command input line). If a parameter has a set of possible values, the list of values is presented from which you may select a value:
Figure 448 : A typical parameter dialog
|
|
In this dialog, the values can be sorted alphabetically by clicking the Sort button. After having entered an initial string, you can also press <Space> to select the first value starting with this string, or press `?' to select the first value containing this string. Additional <Space> or `?' characters will select the next value, etc. When there are no more matches, a real space or `?' character will be added after the string you initially entered.
File parameters are prompted for in File Selection Dialogs. Other parameters, like integers, are prompted for in a simple text input dialog.
If a command parameter is an output signal and you select a signal which in turn have parameters, the signal parameters are asked for in a separate dialog. In this dialog, all parameters are listed with their default ("null") values:
Figure 449 : Editing signal parameters
|
|
To edit a signal parameter, you select the parameter and then edit the value displayed in the input field. If the parameter is of an enumerated type, the possible values can also be selected from the option menu just above the input field. By clicking Default value, the "null" value will be inserted in the input field. A changed parameter value is not updated in the parameter list until a parameter is selected in the list.
Click OK to accept all parameter values, and Cancel to abort the monitor command. The validity of the parameter values is not tested until you click the OK button.
To undo a previous command, click the Undo quick button in the tool bar, or select Undo in the popup menu that is available in the text area. Then you get a dialog with all commands you have given so far. All commands are shown, even the ones entered using buttons or menu choices.
Figure 450 : Undoing a command
|
|
Initially all commands except the last is selected. If you click OK the simulation is restarted and all the selected commands will be re-executed. By clicking on the commands in the dialog you can decide which commands you want to be re-executed in the restarted simulation.
|
Note: The Undo function cannot handle to undo commands for setting or removing graphical breakpoints. |
To redo a command in the current simulation, select Command in the popup menu in the text area. Then you also get a dialog with all commands you have given so far, in the same way as for Undo.
Figure 451 : Redoing a command
|
|
After selecting one of the commands and clicking OK the command is executed. You can also change the command on the command line before clicking OK.
In the Simulator UI, you may change the contents and appearance of button modules and some additional windows. All these configurations are stored in a number of definition files, which are read at start-up of the Simulator UI. If you change any of the configurations, you are prompted to save them when you exit the Simulator UI.
You may wish to add your own command buttons for frequently used commands, or to change or delete existing command buttons. These operations are invoked from the Group menu in the button modules:
|
|
To add a button to a module:
|
|
|
Note: You cannot specify the location of the button in the module. It will be placed in the next available empty position. |
To change an existing button in a module:
Figure 454 : Selecting a button
|
|
To delete an existing button in a module:
In addition to the command buttons, you may also add, rename, delete and collapse/expand the button modules.
Modules may be collapsed and expanded to only show the command buttons of interest at the moment. A collapsed module hides all of its buttons and only displays the title bar:
Figure 455 : A collapsed button module
|
|
To collapse and expand a module, click the toggle button to the left of the module name in the title bar.
To collapse and expand all modules, select Collapse Groups or Expand Groups in the Buttons menu.
To add a new module to the bottom of the button module area, select Add Group in the Buttons menu. In the dialog, enter the module's name and click OK.
To delete a module, select Delete Group from the module's Group menu. In the confirmation dialog, click OK.
To rename a module, select Rename Group from the module's Group menu. In the dialog, enter a new name and click OK.
In the Simulator UI, you can continuously view the internal status of the system by using the Command and Watch windows. These windows are opened from the View menu. They are both updated automatically whenever the monitor system becomes active.
In the Command window, you can execute a number of monitor commands automatically. The commands are executed in command modules, similar to button modules in the main window of the Simulator UI:
Figure 456 : The Command window
|
|
By default, the commands List-Ready-Queue and List-Process are executed. You are advised to only use commands for examining the system, see Examining the System.
The command modules are managed in the following ways:
In the Watch window, you can automatically monitor values of variables in the system. The variables are displayed on separate lines in the window:
|
|
By default, the Watch window is empty. To add a variable, select Add from the Watch menu. In the dialog, enter the variable specification and click OK. A variable specification consists of the process instance name within parenthesis, followed by the variable name, e.g. .
(game:1) count
To change a variable specification, select Edit from the Watch menu. In the dialog, select the variable to edit and click OK. In the next dialog, you can edit the specification and click OK.
To delete a variable specification, select Delete from the Watch menu. In the dialog, select the variable to delete and click OK.
When the SDL system is executing during simulation, you can obtain trace information of the execution. This makes it easier to follow the events that happen during execution.
There are three types of execution traces:
The amount of trace is determined by a trace value for each of the three trace types. The trace value controls the level of detail in the trace; the trace value 0 (zero) means no trace. Setting appropriate trace levels is often something you would like to do before the execution is started.
Apart from these continuous trace functions, there are also other possibilities to trace the execution. See Other Tracing Functions.
Trace values can be assigned to different units of the SDL system; the system as a whole, blocks, process types, and process instances.
System Demongame
Block GameBlock
Process Game
In this diagram structure, the unit name "Game" would refer to the block GameBlock. To specify the process Game instead, the unit could be expressed as "process Game" or "<<System Demongame / Block GameBlock>> Game".
When a process instance executes a transition, or part of a transition, the trace value for the instance is found using the following algorithm:
For MSC trace the situation is slightly more complex; see MSC Trace.
Textual trace is printed for the transition or the SDL symbols that were last executed.
To quickly set the maximum textual trace level (6) for the system, click the TEXT button in the Trace module.
The general procedure to set the trace value for textual trace is:
<Return> in stand-alone mode. The following table explains them in more detail; for a full explanation, see Trace Limit Table. The default textual trace value is 4 for the system.
To list the textual trace values that are defined for the units in the system, choose Trace Level : Show in the Trace menu, or enter the command List-Trace-Values.
You can also reset the trace value for textual trace for a unit, i.e., set it to undefined. To do this, enter the command Reset-Trace and specify a unit (there is no button for this command).
GR trace will open an SDL Editor and continuously select the next SDL symbol to be executed in the corresponding process diagram. (See also Tracing Simulations (Graphical Trace).)
To quickly set the GR trace level for the system to 1 (see below), click the SDL button in the Trace module.
The general procedure to set the trace value for GR trace is:
<Return> in stand-alone mode. The following table explains them in more detail. The default GR trace value is 0 for the system.
To list the GR trace values that are defined for the units in the system, choose SDL Level : Show in the Trace menu, or enter the command List-GR-Trace-Values.
You can also reset the trace value for GR trace for a unit, i.e., set it to undefined. To do this, enter the command Reset-GR-Trace and specify a unit (there is no button for this command).
MSC trace will enable transformation of the SDL events that take place during execution into corresponding MSC events. Of course, not all SDL events are possible to transform into MSC events; typically, the events that can be transformed are sending and consumption of signals, setting and expiration of timers, and creation and termination of processes. By default, this transformation is enabled for the whole system.
The MSC events that are created by MSC trace can then be logged in two different ways:
Therefore, setting the MSC trace value does not start the actual logging of MSC events in an MSC Editor or on file.
To set the trace value for MSC trace:
<Return> in stand-alone mode. The following table explains them in more detail; for a full explanation, see Message Sequence Chart Traces. The default MSC trace value is 1 for the system.
To list the MSC trace values that are defined for the units in the system, choose MSC Level : Show in the Trace menu, or enter the command List-MSC-Trace-Values.
You can also reset the trace value for MSC trace for a unit, i.e., set it to undefined. To do this, enter the command Reset-MSC-Trace and specify a unit (there is no button for this command).
To start the continuous logging of MSC events in an MSC Editor:
To quickly start the continuous logging of MSC events in an MSC Editor with symbol level 1, click the MSC button in the Trace module.
To start the continuous logging of MSC events in a log file:
.mpr.When an MSC log is started, the amount of information that should be part of the log can be decided by giving the symbol level parameter an appropriate value, according to the table below:
Note that you cannot have both types off logging enabled at the same time. To see what type of logging is enabled, enter the command List-MSC-Log (this command has no button).
To stop the logging, choose MSC Trace : Stop in the Trace menu, or enter the command Stop-MSC-Log. If you used logging to an MSC Editor, you should then save the trace from the editor. If you used logging to file, the file is automatically saved and closed.
If you do not have GR trace enabled, it is still possible to show the next symbol to be executed in an SDL Editor. To do this, choose
Next Symbol in the Show menu, or enter the command Show-Next-Symbol.
In a similar fashion, the last executed symbol can be shown in an SDL Editor. This will give you a correspondence between textual trace and the SDL Editor, since textual trace always is printed for the last executed symbols. To do this, choose Prev Symbol in the Show menu, or enter the command Show-Previous-Symbol.
A trace-back to the generated C source code for the system is also possible. To show where in the C code the execution is at the moment, choose C Line in the Show menu, or enter the command Show-C-Line-Number. The file name and line number of the C source file is printed, and the C source file is opened in the Text Editor, positioned on the correct line.
To see how much of the SDL system you have covered during simulation, you can open the coverage information in a Coverage Viewer, and for instance examine which parts of the system that have not been executed during the simulation. To start the Coverage Viewer, choose Coverage in the Show menu, or enter the command Show-Coverage-Viewer.
There are a number of monitor commands for executing one or more transitions in process instances, and for stepping symbol by symbol within a transition.
|
Note: During execution, you may be prompted for input before the execution can continue. See Run-time Prompting for more information. |
To start executing the simulation program continuously, click the Go button in the Execute module, or enter the command Go. The execution continues until one of the conditions listed in Activating the Monitor becomes true, for instance when reaching a breakpoint. See also Stopping the Execution.
|
Note: The button Forever, corresponding to the command Go-Forever, behaves very similar to the above. The difference is that the monitor does not become active when the system is completely idle. This feature is valuable when communicating with other simulations or applications. |
To execute until a certain point in time:
To execute until, but not including, the next timer output, click the Until Timer button in the Execute module, or enter the command
Proceed-To-Timer.
To execute the next transition, or the remainder of the current transition, click the Transition button in the Execute module, or enter the command Next-Transition.
To execute a number of transitions until a transition with a textual trace value > 0 has been executed, choose Until Trace in the Execute menu, or enter the command Next-Visible-Transition. This is very valuable when you have set the trace value for some "uninteresting" parts of the system to 0, and you want to skip over those parts.
To execute only the next SDL symbol, choose Over Symbol in the Execute menu, or enter the command Next-Symbol. This may execute several statements, and will step over procedure calls.
To execute only the next SDL statement, choose Over Stmt in the Execute menu, or enter the command Next-Statement. This will step over procedure calls.
The only way to follow the execution into a procedure is to use the following single-stepping functions.
To execute only the next SDL symbol, and to step into possible procedure calls, click the Symbol button in the Execute module, or enter the command Step-Symbol. This may execute several statements.
To execute only the next SDL statement, and to step into possible procedure calls, choose Into Stmt in the Execute menu, or enter the command Step-Statement.
To execute a procedure up to and including its return, choose Finish in the Execute menu, or enter the command Finish. In a process, this command behaves exactly like Next-Transition.
To stop the execution of transitions and symbols manually:
<Return> during printing of trace information (repeatedly, if necessary). No other characters may be typed before <Return> is pressed.
In the Simulator, you can issue a number of monitor commands to examine the internal status of the system. Detailed information concerning processes, procedure calls, signals, timers, and variables can be requested. Using the Simulator UI, you may continuously view the internal status by using the Command and Watch windows; see The Command and Watch Windows.
Some of the commands used for examining the system operate on a specific process instance, the current process, identified by the current scope. A scope is a reference to a process instance, a reference to a service instance if the process contains services, and possibly a reference to a procedure instance called from this process/service (the current procedure). The scope is also used by some of the commands for modifying the system; see Modifying the System.
The scope is automatically set by the execution commands, when entering the monitor, to the next process instance in turn to execute. You may change the scope if you would like to examine (or modify) another process, service or procedure instance. Changing the scope does not change the execution order of process instances. As soon as the execution continues again, the scope is reset to the next process instance in turn to execute.
To print the current process/service scope enter the command Scope.
To set the current process/service scope:
The scope is set to the specified process/service, at the bottom procedure call.
To print the procedure call stack for the process/service instance defined by the current scope, choose Call Stack in the Examine menu, or enter the command Stack.
To change the procedure scope within the current process/service scope, you can move the scope one step up or down in the procedure call stack by entering the command Up or Define-MSC-Trace-Channels. Going up from a service leads to the process containing the service. To go down in a service within a process, select or enter the name of the service instance.
To print the current value of the simulation time, in case it is not displayed by the textual trace, choose Now in the Examine menu, or enter the command Now.
The ready queue is the queue of process instances that are ready to execute a transition, i.e., those instances that have received a signal that can cause an immediate transition, but that have not yet had the opportunity to execute this transition to its end.
To print an ordered list of the process instances in the ready queue, choose Ready Q in the Examine menu, or enter the command List-Ready-Queue. The list contains an entry number (queue position), the process instance, its current state, the number of signals in its input port, and the name of the signal that will cause the next transition. If a process instance has active procedure calls, the current executing procedure instance is also listed. If the state name is followed by a `*', then the process/procedure is currently executing a transition starting from this state.
The ready queue is by default printed in the Command window. It may look like this:
Figure 458 : The ready queue in the Command window
|
|
To list all active process instances of a certain process type:
To print information about the current process instance, enter the command Examine-PId. The information contains the current values of Parent, Offspring, Sender and a list of all currently active procedure calls made by the process instance (the stack). For more information on current process and procedure call stack, see Current Process and Scope. An example of output is:
Parent : null Offspring : Game:1 Sender : env:1 PId Main:1
To list all signal instances in the input port of the current process instance, choose Input Port in the Examine menu, or enter the command List-Input-Port. The list contains an entry number (queue position), the signal type, and the sending process instance. If the entry number is prefixed by a `*', the signal instance is the one to be consumed in the next transition performed by the process instance. For more information on the current process, see Current Process and Scope. An example of output is:
Input port of Game:1 Entry Signal name Sender *1 Bump Demon:1 2 GameOver Main:1
To print the parameters of a signal instance in the input port of the current process instance:
Signal name : Score Parameter(s) : -1
To list all active timers in the system, choose Timer List in the Examine menu, or enter the command List-Timer. The list contains an entry number, the timer name, the corresponding process instance, and the associated time. An example of output is:
Entry Timer name PId Time 1 T Demon:1 4.0000
To print the parameters of an active timer instance:
To print the value of a variable or formal parameter in the current process or procedure:
To examine variables or formal parameters in any process, click the Variable button in the Examine module. In addition to the variable name and component (as described above), you will be prompted for the process name.
By setting breakpoints in the system, the execution of a simulator can be stopped and the monitor system activated at a certain point of interest. They can be used to trap certain SDL symbols, transitions, signal outputs, and variable changes.
Breakpoints are often used together with continuous execution to reach a certain state of the system (see Continuous Execution). The monitor system becomes active when the breakpoint condition becomes true. Care should be taken when using continuous execution with breakpoints; if the breakpoint is never reached, the system may continue executing "forever."
When defining a breakpoint, you may specify one or more monitor commands to be executed after the breakpoint has been reached. In this way it is possible to, for instance, automatically print information about the system by using the examine commands. The monitor commands are specified using the same syntax as when entering them textually.
If you want to use several monitor commands, they have to be separated by spaces and semicolons. It is even possible to use the execution commands in this context to automatically continue the execution after a breakpoint has been reached. However, care should be taken to make sure the system does not end up executing "forever." An example of a combination of breakpoint commands may be:
Examine-PId ; Go
Symbol breakpoints are set on a specific SDL symbol. Symbol breakpoints are checked before a symbol is executed, i.e., the symbol is not executed when the breakpoint is reached.
There are two ways to set a symbol breakpoint, either graphically by selecting the SDL symbol directly in the SDL Editor, or textually by specifying an SDT reference to the SDL symbol.
When a symbol breakpoint has been set, the breakpoint is indicated by a red "stop" sign placed at the SDL symbol in the SDL diagram.
To set a symbol breakpoint graphically using the SDL Editor:
To set a symbol breakpoint textually using an SDT reference:
<Ctrl+C> to copy.<Ctrl+V> (in Windows), or click the middle mouse button (on UNIX), to paste the textual SDT reference. The two dialogs should now look like this:
Figure 459 : Copying an SDT reference
|
|
Transition breakpoints are set on a transition, i.e. the combination of a process instance, state, signal and sender. Transition breakpoints are checked before a transition is executed, i.e., the transition is not executed when the breakpoint is reached.
To set a transition breakpoint:
Output breakpoints are set on a signal output, i.e. the combination of a signal, sender process and receiver process. Output breakpoints are checked immediately after a signal is sent.
To set an output breakpoint:
Variable breakpoints are set on a specific variable and are triggered whenever the value of the variable is changed. Variable breakpoints are checked after a variable assignment, i.e., the execution stops immediately after the symbol or assignment statement where the value was changed.
To set a breakpoint on a variable in the current process:
To list all defined breakpoints, choose List in the Breakpoint menu, or enter the command List-Breakpoints. The list contains an entry number and the break condition for each breakpoint, i.e. the values of the parameters specified when the breakpoint was defined. An omitted parameter value, where permitted, is listed as "any."
A symbol breakpoint can be visualized by opening the SDL diagram and selecting the SDL symbol in an SDL Editor. To see where a specific symbol breakpoint has been defined:
To remove a defined breakpoint using the Simulator UI:
To remove all symbol breakpoints set on an SDL symbol:
To remove all defined breakpoints:
Usually, you have to send signals into the system to make something of interest happen, for instance when the system is completely idle. You can send signals directly to a process instance, or indirectly by specifying a channel.
To send a signal from the environment to a certain process:
To send a signal from the environment via a channel:
To send a "none" signal to a process, i.e. to try to cause a spontaneous transition in the process:
The following types of interaction during simulation can be logged to file:
|
Note: The logging of MSC events to file is described in MSC Trace and Logging. |
To start logging of all issued monitor commands from now on:
.com.To stop the logging, select Stop Command Log from the Log menu, or enter the command Command-Log-Off.
After logging has been stopped, it can be continued on the same log file, i.e. the existing log file is appended, or on a new log file.
To continue logging of monitor commands:
Figure 460 : Continued logging on an existing file
|
|
All monitor commands issued by the user so far in the Simulator UI session can also be saved on a command file, without starting continuos logging of commands. To do this, select Save from the popup menu on the input line and select a command file.
A command log file may later be read in and executed to repeat the same command session. To do this:
Complete logging of all user interaction works in the same way as logging of monitor commands, described above. The only difference is the name of the menu choices and commands. Either select Start Complete Log and Stop Complete Log from the Log menu, or enter the commands Log-On and Log-Off.
The signals that are sent to, from or via a unit in the system can be logged on file. The signal log file will contain a line for each signal sent, including the simulation time, the name of the signal, the sender process instance and the receiver process instance. Values of signal parameters are also printed.
More than one signal log can be active at a time, each one in a separate log file.
To start a signal log:
To list the active signal logs, enter the command List-Signal-Log (this command has no associated button). The list contains an entry number, the unit name and the log file name.
To stop a signal log:
The are a number of commands that change the behavior of the simulated system. These commands are useful to make debugging easier. They can, for example, be used to recover from logical errors, or to put the system in a state that could be difficult to achieve otherwise.
Some of these commands operate on the current process. For more information on the current process, see Current Process and Scope.
To simulate the sending of an internal signal between two process instances:
The signal is put in the input port of the receiver process, if it is in the valid input signal set; otherwise, it is discarded. No checks are made whether a path exists between the sender and the receiver.
To change the state of the current process, service, or procedure:
To create a new process instance:
Attempt to create more than the max number of concurrent instances. Do you still want to create the instance :
To stop a running process instance:
To set a timer in the current process:
To reset a timer in the current process:
To change the value of a variable in the current process:
To remove a signal instance in the input port of the current process:
|
Note: Entry numbers are just positions in the input port. The removal of a signal changes the entry numbers of the remaining signals. |
To change the placing of a signal instance in the input port of the current process:
You can change the order of process instances in the ready queue, i.e. the execution order of processes.
To change the placing of a process instance in the ready queue:
To exit a simulator, choose Stop Sim in the Execute menu, or enter the command Exit or Quit. If the command is abbreviated, you have to confirm the exit operation; the following message appears:
Do you really want to exit program :
Enter `y' or `Y' to exit; all other answers cancels the exit.
To exit the Simulator UI, select Exit from the File menu. If you have changed the configuration of the Simulator UI, you are asked whether to save these changes. See Customizing the Simulator UI. If you save them under the default file names, they are read in and restored the next time the Simulator UI is started.
The following dialogs may appear:
Figure 461 : Saving button changes
|
|
Click Save if you want to save the changes you have made to buttons and button modules. A File Selection Dialog is opened with the filter *.btns; the default name of the file is def.btns. Click Cancel to cancel the exit.
Figure 462 : Saving command changes
|
|
Click Save if you want to save the changes you have made to commands in the Command window; a File Selection Dialog is opened with the filter *.cmds; the default name of the file is def.cmds. Click Cancel to cancel the exit.
Figure 463 : Saving variable changes
|
|
Click Save if you want to save the changes you have made to variables in the Watch window; a File Selection Dialog is opened with the filter *.vars; the default name of the file is def.vars. Click Cancel to cancel the exit.