Table of ContentsTable of Contents 
Previous Chapter
The textual interface is invoked by executing the generated simulator directly from the operating system prompt. When started, the simulator responds with the following text:
Welcome to SDT SIMULATOR. Simulating system <system> Command :The graphical interface, known as the Simulator UI, runs in a separate window. It is invoked from the Organizer by selecting the command Simulator UI from the Tools menu (see page 1129). The Simulator UI is described in "Graphical User Interface" on page 1839.------------------------------------------------------------------ Note: Before a simulator can be run in stand-alone mode, a command file must be executed from the operating system prompt. The file is called telelogic.sou or telelogic.profile and is located in the SDT binary directory that is included in the user's path. ------------------------------------------------------------------
------------------------------------------------------------------ Note: No other characters may be typed before <Return> is pressed. ------------------------------------------------------------------
Command :The syntax to be used for the commands and their parameters are described in the following.
Consider, as an example, the command name ListProcess. The command name may be typed List-P or L-P. However, if only List is typed, the monitor system will respond with the message
Command was ambiguous, it might be an abbreviation of:followed by a list of all commands starting with "List," since the command cannot be distinguished from, for example, the commands ListReadyQueue and ListTimer.
There is no distinction made between upper and lower case letters when matching command names.
Parameters may be abbreviated as long as the parameter value does not become ambiguous. There is no distinction made between upper and lower case letters.
----------------------------------------------------------- Note: The SDL keywords Sender, Parent and Offspring may not be ab breviated. -----------------------------------------------------------
The abbreviation facility means that the introduction of underscores in SDL names simplifies simulation. If, for example, you were considering if two signals should be named GenerateOn and GenerateOff or if they should be named Generate_On and Generate_Off, the last alternative is preferable for simulations, as the abbreviations G_On and G_Off are likely to be unique.
Signal names and timer names are in the same entity class; process formal parameters and process variables are in the same entity class; each other type of name (process, procedure, state, block,...) is in an entity class of its own.
Knowledge of previous parameters is used to narrow the search for a given parameter name. Consider for example the command OutputVia, which takes two parameters, a signal and a channel. The channel name is then only searched for among the channels the given signal can be sent via.
In the first situation the process name will always be ambiguous and in the second case the system's signal will always be used. To solve cases like this, qualifiers with the same syntax as in SDL can be used. To reach a process P defined in block B in system S, the following notations can be used:
System S / Block B P <<System S / Block B>> PThe words "system," "block," "process," "procedure," and "substructure" in the qualifier may not be abbreviated, while all names of, for example, blocks and processes may be abbreviated according to the usual rules. It is only necessary to give those parts of the qualifier that make the qualifier path unique (this is an extension of the qualifier concept in SDL). The slash ( / ) in a qualifier may be omitted and replaced by one or more spaces. The angle brackets that are part of the qualifier when printed may be omitted when entering the qualifier.
If the parameter is given on the same line as the command name and/or other parameters, type a hyphen `-' to indicate a default parameter value.
Example 43 Default Parameters in Simulator CommandConsider as an example the command BreakpointTransition, which takes at least eight parameters.
To specify default values for all parameters, except the first and fourth parameter:
Breakpoint-Transition P - - State1 - - - -
Example 44 : Signal and Timer Parameters in Simulator Command Signal name : S Parameter 1 (Integer) : 3 Parameter 2 (Boolean) : trueThe same specification could also be given as:
Signal name : S 3 trueor as:
Signal name : S (3 true)
If no default value exists for the requested parameter, the list of all allowed values is also printed if the user simply presses <Return> at the prompt. In these cases, there is no need to type `?'.
Example 45 : Real Values in SimulatorThe real number 1.4527 * 1024 can be written 1.4527E24
The real number 4.46 * 10-4 can be written 4.46E-4
Example 46 : Time Values in Simulator123.5 is interpreted as 123.5
+5.5 is interpreted as NOW + 5.5
-8.0 is interpreted as NOW - 8.0
Example 47 : Character Values in Simulator 'a', '3', '''', ' ', NUL, DELOn input, the quotes may be omitted for all characters except ` ' (space) and `[`. A ` should be entered as `'''.
Example 48 : Charstring Values in Simulator--------------------------------------- '' An empty string 'abc' A string of three characters 'a'NUL'c' The second character is NUL ---------------------------------------
The first process instance of a process type that is created will have instance number 1, the second that is created will have instance number 2, and so on. The syntax is Name:No, where Name is the process name and No is the instance number.
On input the process name and the instance number may, as an alternative, be separated by one or more spaces, if the command parameter is a PId value. In the same circumstances the instance number is not necessary (and will not be prompted for) if there is only one process instance of the process type. If, however, the command parameter is a unit that might be a process type or a process instance, only a colon (`:') is allowed between the process name and the instance number and the colon must follow directly after the process type name. Examples of such situations are the unit parameter in SetTrace and SignalLog.
On output a PId value may be followed by a plus sign (`+'), which indicates that the process instance is dead; that is, has executed a stop action. The plus sign is chosen as it is reminiscent of the `' character.
There are two syntaxes for array components depending on the implementation that the C Code Generator has selected for the array implementation. This selection is described in the chapter about the C Code Generator, see "Array" on page 1983. These easiest way to determine which syntax to use on input is to look at a variable of the array sort.
(: 1, 10, 23, 2, 11 :)
(: (others:2), (10:3), (11:4) :)This would mean that for index 10 the value is 3, for index 11 the value is 4, and for all other indexes the value is 2. On input the commas, the parenthesis, and the colons in the components may be replaced by one or more spaces (or carriage returns or tabs).
(. 1, 3, 6, 37 .)On input the commas can be replaced by one or more spaces (or carriage returns or tabs).
[ 1, 3, 6, 37 ]On input the commas can be replaced by one or more spaces (or carriage returns or tabs).
(None)The monitor will repeatedly look at the keyboard for a carriage return, indicating an immediate break in the execution of the current transition. Using the command @, this facility can be turned off. Each time the command @ is entered the monitor toggles between having the keyboard polling for carriage return on and off. At start up keyboard polling is on.
-------------------------------------------------------------------- Note: No other characters may be typed together with the carriage return. If some other characters are typed by mistake, please delete them be fore typing the carriage return. --------------------------------------------------------------------To turn keyboard polling off is useful in some situations, for example if a user wants to paste a sequence of commands into the monitor. If the sequence contains an empty line this might cause an unwanted interrupt.
(None)The monitor will respond to a `?' (question mark) by giving a list of all allowed values at the current position, or by a type name, when it is not suitable to enumerate the values. After the presentation of the list, the input can be continued.
Typing `?' at the prompt level gives a list of all available commands, after which a command can be entered. For further help, see the command Help.
<Variable name> <Optional component selection>The new value is assigned to the specified variable in the process instance, service instance, or procedure given by the current scope. Sender, Offspring, and Parent may also be changed in this way, but their names may not be abbreviated.
<New value>
It is, in a similar way as for the command ExamineVariable, possible to handle components in structured variables (struct, strings and array) by appending the struct component name or a valid array index before the value to be assigned. Nested structs and arrays can be handled by entering a list of index values and struct component names.
<SDT reference> <Optional breakpoint commands>A breakpoint is defined at the symbol specified by the SDT reference. If the execution reaches the symbol, the monitor becomes active immediately before that symbol. SDT references may be obtained by using the Show GR Reference command in an Editor, see page 1218.
The <Optional breakpoint commands> parameter can be used to give monitor commands that should be executed when the breakpoint is triggered. Monitor commands should be separated by " ; ", i.e. space semicolon space.
<Signal name> <Sender process name>A breakpoint is activated and a breakpoint condition is defined. If a breakpoint condition is matched by an output, the monitor becomes active immediately after the symbol containing the output. The breakpoint condition defines one or several outputs and is specified by the parameters. Any of the parameters may be omitted, which implies that any value will match the missing fields in the breakpoint condition. Initially no breakpoints are active.
<Sender instance number> <Receiver process name>
<Receiver instance number> <Counter>
<Optional breakpoint commands>
The <Counter> parameter is used to indicate how many times the breakpoint condition should be true before the monitor should become active. Default value for this parameter is 1, which means that the monitor should be activated each time the breakpoint condition is true.
The <Optional breakpoint commands> parameter can be used to give monitor commands that should be executed when the breakpoint is triggered. Monitor commands should be separated by " ; ", i.e. space semicolon space.
<Process name> <Instance number> <Service name>A breakpoint is activated and a breakpoint condition is defined. If a breakpoint condition is matched by a transition, the monitor becomes active immediately before that transition is started. The breakpoint condition matches one or several transitions and is specified by the parameters. Any of the parameters may be omitted, which implies that any value will match the missing fields in the breakpoint condition. Initially no breakpoints are active.
<State name> <Signal name> <Sender process name>
<Sender instance number> <Counter>
<Optional breakpoint commands>
The <Counter> parameter is used to indicate how many times the breakpoint condition should be true before the monitor should become active. Default value for this parameter is 1, which means that the monitor should be activated each time the breakpoint condition is true.
The <Optional breakpoint commands> parameter can be used to give monitor commands that should be executed when the breakpoint is triggered. Monitor commands should be separated by " ; ", i.e. space semicolon space.
<Variable name> <Optional breakpoint commands>A breakpoint is defined on the specified variable in the process instance given by the current scope. If the variable's value is changed, the monitor becomes active immediately after the symbol or assignment statement where the value is changed. The value is only checked between symbols and between assignment statements in tasks.
The breakpoint is also triggered when the variable no longer exists, i.e. the PId containing the variable is stopped or the procedure containing the variable has reached its end. In this case, the breakpoint is automatically removed.
The <Optional breakpoint commands> parameter can be used to give monitor commands that should be executed when the breakpoint is triggered. Monitor commands should be separated by " ; ", i.e. space semicolon space.
(None)The CallEnv command performs one call of the function InEnv. See the command StartEnv for more details.
--------------------------------------------------------------- Note: This command and the commands StartEnv and StopEnv are only available when the C Code Generator is used to generate applica tions. ---------------------------------------------------------------
(None)The command makes one call to the function that looks for incoming signals from the SDT communication mechanism. This means that all signals that have come to the simulator will be sent to their appropriate receiving process instances. See the command StartSDTEnv for more details.
<Entry number>Stops the signal log with the specified entry number and closes the corresponding log file; see the command SignalLog for more details. Entry numbers assigned by the command ListSignalLog should be used.
(None)The command log facility is turned off; see the command CommandLogOn for details.
<Optional file name>The command enables logging of all the commands given in the monitor. The first time the command is entered a file name for the log file has to be given as parameter. After that any further CommandLogOn commands, without a file name, will append more information to the previous log file, while a CommandLogOn command with a file name will close the old log file and start using a new file with the specified name.
Initially the command log facility is turned off. It can be turned off explicitly by using the command CommandLogOff.
The generated log file is directly possible to use as a file in the command IncludeFile. It will, however, contain exactly the commands given in the session, even those that were not executed due to command errors. The concluding CommandLogOff command will also be part of the log file.
<Process name> <Parent's PId value>A process instance of the specified process type is created. If the parent PId is not equal to null, Offspring is set in the specified parent instance. If the number of instances of the specified process type is greater than or equal to the maximum number of concurrent instances, the user has to verify the create action.
<Process parameters>
<Optional service name>Moves the scope one step down in the procedure call stack. If the current scope is a process containing services, one of the services should be specified. See also the commands Stack, SetScope and Up.
(None)Information about the process instance given by the current scope is printed (see the SetScope command for an explanation of scope). This 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). The list starts with the latest procedure call and ends with the process instance itself. If the process contains services, these services will be listed, each with its own procedure call stack.
<Entry number>The parameters of the signal instance at the position equal to entry number in the input port of the process instance given by the current scope are printed (see the SetScope command for an explanation of scope). The entry number is the number associated with the signal instance when the command ListInputPort is used.
<Entry number>The parameters of the specified timer instance are printed. The entry number is the number associated with the timer when the ListTimer command is used.
<Optional variable name>The value of the specified variable or formal parameter in the current scope is printed (see the SetScope command for an explanation of scope). Variable names may be abbreviated. If no variable name is given, all variable and formal parameter values of the process instance given by the current scope are printed. Sender, Offspring, and Parent may also be examined in this way. Their names, however, may not be abbreviated and they are not included in the list of all variables.
<Optional component selection>
------------------------------------------------------------------------- Note: If a variable is exported, both its current value and its exported value are printed. -------------------------------------------------------------------------It is possible to examine only a component of a struct, string or array variable, by appending the struct component name or a valid array index value as an additional parameter. The component selection can handle structs and arrays within structs and arrays to any depth by giving a list component selection parameters. SDL syntax with `!' and "( )" as well as just spaces, can be used to separate the names and the index values.
It is also possible to print a range of an array by giving "FromIndex : ToIndex" after an array name. Note that the space before the `:' is required if FromIndex is a name (enumeration literal), and that no further component selection is possible after a range specification.
To see the possible components that are available in the variable, the variable name must be appended by a space and a `?' on input. A list of components or a type name is then given, after which the input can be continued. After a component name, it is possible to append a `?' again to list possible sub components.
(None)The simulation is terminated. If the command is abbreviated the monitor asks for confirmation. This is the same command as Quit.
(None)This command will execute the currently executing procedure up to and including its return, i.e. it will finish this procedure. The execution will also be interrupted at the end of the transition. In a process, Finish will behave just like the command NextTransition.
(None)The execution of the simulation is resumed. The execution will continue until one of the conditions listed in "Activating the Monitor" on page 1786 becomes true. To stop the execution of transitions, press <Return> (and only this key). The interactive monitor will then become active when the execution of the current SDL symbol is completed.
This command has to be used with care in the interactive monitor, as it might result in executing the simulation program "forever" (if none of the conditions for activating the monitor becomes true). In a catastrophic situation (e.g. an endless loop within an SDL symbol) it is possible to terminate the program by using the way to stop the execution of a program defined in the operating system (<ctrl-c> on UNIX).
(None)The command GoForever behaves, in most situations, in the same way as the command Go.
For GoForever to behave differently than Go, there has to be an environment to the SDL system that can send signals to the SDL system (communicating simulations or environment functions). When the command Go is issued and the SDL system becomes completely idle (no possible transition and no active timer) the monitor becomes active again and is entered. If GoForever was used instead of Go, the monitor is not entered in this case; instead the simulation continues to wait for external stimulus. This feature is valuable when a simulation communicates with other simulations or applications.
<Optional command name>Issuing the Help command without a parameter will print all the available commands. If a command name is given as parameter, this command will be explained.
<File name>This command provides the possibility to execute a sequence of monitor commands stored in a text file. The IncludeFile facility can be useful for including, for example, an initialization sequence or a complete test case. It is allowed to use IncludeFile in an included sequence of commands; up to five nested levels of include files can be handled.
(None)All active breakpoints are listed. Each breakpoint is assigned an entry number that can be used in the RemoveBreakpoint and ShowBreakpoint commands.
(None)The values of all currently defined GR traces are listed. The list contains the trace unit type (system, block, process, PId), the unit name, and the GR trace value (both numeric and a textual explanation). See also the commands SetGRTrace and ResetGRTrace.
(None)A list of all signal instances in the input port of the process instance given by the current scope is printed (see the SetScope command for an explanation of scope). For each signal instance an entry number, the signal type, and the sending process instance is given. A `*' before the entry number indicates that the corresponding signal instance is the signal instance that will be consumed in the next transition performed by the process instance. The entry number can be used in the commands ExamineSignalInstance, RearrangeInputPort and RemoveSignalInstance.
(None)This command returns the current status of the MSC log (off / interactive / batch). See also the commands StartInteractiveMSCLog, StartBatchMSCLog and StopMSCLog.
(None)This command returns the current status for the MSC trace parameters. The list contains the trace unit type (system, block, process, PId), the unit name, and the MSC trace value (both numeric and a textual explanation). See also the commands SetMSCTrace and ResetMSCTrace.
<Optional process name>A list of all process instances associated with the specified process type is produced. If no process name is specified all process instances in the system are listed. The list will contain the same details as described for the ListReadyQueue command.
(None)A list is produced containing the process instances in the ready queue, 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. If the process contains services, the currently active service is also listed. If a process/service instance has active procedure calls, the current executing procedure instance is also listed. For each instance in the list the following information is given:
The entry number can be used in the command RearrangeReadyQueue.
(None)Print information about the currently active signal log; see the command SignalLog for more details. Each log is assigned an entry number which can be used in subsequent CloseSignalLog commands.
(None)A list of all currently active timers is produced. For each timer, its corresponding process instance and associated time is given. An entry number will also be part of the list, which can be used in the command ExamineTimerInstance.
(None)The values of all currently defined traces are listed. The list contains the trace unit type (system, block, process, PId), the unit name and the trace value (both numeric and a textual explanation). See also the commands SetTrace and ResetTrace.
(None)The command LogOff turns off the interaction log facility, which is described in the command LogOn.
<Optional file name>The command LogOn takes an optional file name as a parameter and enables logging of all the interaction between a simulation program and the user that is visible on the screen. The first time the command is entered, a file name for the log file has to be given as parameter. After that any further LogOn commands, without a file name, will append more information to the previous log file, while a LogOn with a file name will close the old log file and start using a new file with the specified file name.
Initially the interaction log facility is turned off. It can be turned off explicitly by using the command LogOff.
(None)The News command summarizes the changes in the textual monitor user interface from the previous SDT release.
<Optional number of statements>This command is used to step statement for statement through SDL transitions. A statement is the same as a symbol, except that a task symbol may contain several assignment statements; compare with the NextSymbol command.
NextStatement steps over procedure calls, i.e. all actions in the procedure will be executed and the monitor will be entered again when the statement after the procedure call is reached; compare with the StepStatement command.
After making the step(s) the monitor is entered, making it possible to, for example, examine the temporary status of the actual process instance.
------------------------------------------------------------------- Note: The right hand side of an assignment may contain a value returning procedure call. -------------------------------------------------------------------
<Optional number of symbols>This command is used to step symbol for symbol through SDL transitions. A symbol may contain several statements; compare with the NextStatement command.
NextSymbol steps over procedure calls, i.e. all actions in the procedure will be executed and the monitor will be entered again when the symbol after the procedure call is reached; compare with the StepSymbol command.
Using the optional integer parameter, a specified number of symbols can be stepped through. NextSymbol will, however, never step from within one transition into another transition.
After making the step(s) the monitor is entered, making it possible to, for example, examine the temporary status of the actual process instance.
------------------------------------------------ Note: Join is not considered a symbol by this command. ------------------------------------------------To determine how far a transition has been executed, the commands ShowNextSymbol and ShowPreviousSymbol, together with trace printouts and GR traces can be used. The last trace printout is from the last executed symbol (if it has caused a printout, which depends on the trace level), while the symbol next to be executed is selected by the GR trace, if GR trace is on.
(None)The next transition is executed. If real time is used and the next transition is a timer output scheduled in the future (more than a second from now), the command NextTransition will wait one second, after which the monitor is entered again.
Executing a NextTransition command within a transition will execute the remaining part of the transition.
(None)A number of transitions are executed up to and including the next transition with a trace value > 0. For a timer output transition, it is the trace value for the corresponding process instance that is considered.
This command should be used with care in the interactive monitor, as it might result in executing the simulation program "forever" (if no transition with trace>0 is ever executed). To stop the execution of transitions, press <Return>. The interactive monitor will then become active when the execution of the current SDL symbol is completed.
<State name>The state of the process/service/procedure instance given by the current scope is changed (see the SetScope command for an explanation of scope). This command implies that all actions in a nextstate are performed, i.e. recalculation of enabling conditions and continuous signals, and searching for a signal to be received according to the input and save sets. As a consequence the ready queue for process instances may change.
(None)The current value of the simulation time is printed.
<Signal name> <Signal parameters>The command is used to simulate an output of an internal signal instance between two process instances in the system. The parameter <Sender's PId value> may also denote "env:1". No check is made to ensure that a path of signal routes and channels exists. The monitor responds with either of the three messages below.
<Receiver's PId value> <Sender's PId value>
Signal <name> is not in valid input signal set of process <name>The signal was not in the valid input signal set of the receiver and can thus not be handled by the receiver. The signal was immediately discarded.
Signal <name> was sent to <receiver> from <sender>The signal instance was successfully sent and was placed in the input port of the receiver.
Signal <name> caused an immediate null transitionThe receiving process instance is currently waiting in a state where the specified signal type neither may cause an input operation, nor is saved. The signal instance is immediately discarded (in SDL this is called a null transition, i.e a transition with no actions, leading back to the same state).
<PId value> <Optional service name>The command is used to send a signal "none" to the specified process instance. If the process instance contains services, one of the services should to be specified as well. The none signal is used to indicate that a spontaneous transition should be initiated in the current state.
<Signal name> <Signal parameters>The command is used to send a signal from the environment of the system to a process instance in the system. It will be checked that a path of channels and signal routes exists from the environment to the specified process instance.
<Receiver's PId value>
The monitor will respond with either of the messages described below, or by an error message if no path existed.
Signal <name> was sent to <receiver> from <sender>The signal instance was successfully sent and is placed into the input port of the receiver.
Signal <name> caused an immediate null transition.The receiving process instance is currently waiting in a state where the specified signal type neither may cause an input operation, nor is saved. The signal instance is immediately discarded (in SDL this is called a null transition, a transition with no actions, leading back to the same state).
<Signal name> <Signal parameters>The command is used to send a signal from the environment of the system to a process instance in the system via the specified channel. If no channel is given, it is assumed that any channel from the environment to the system may be selected. It will be checked that there exists one process instance that can receive the signal, according to the rules of outputs in SDL.
<Optional channel name>
The monitor will respond with either of the messages below, or by an error message if the number of possible receivers is not equal to one.
Signal <name> was sent to <receiver> from <sender>The signal instance was successfully sent and is placed into the input port of the receiver.
Signal <name> caused an immediate null transition.The receiving process instance is currently waiting in a state where the specified signal type neither may cause an input operation, nor is saved. The signal instance is immediately discarded (in SDL this is called a null transition, a transition with no actions, leading back to the same state).
<File name>This command can be used to obtain test coverage information and profiling information. Each time the command is issued a coverage file, with the name specified as parameter, is produced in the work directory containing the relevant information. The coverage file always reflects the situation from the start of the simulation. To study the information in the coverage file, it can be opened in the Coverage Viewer; see chapter 28, The Coverage Viewer.
------------------------------------------------------------------------ Note: The specified file is always overwritten, i.e. there is no confirmation message if an existing file is specified. ------------------------------------------------------------------------The generated file consists of two sections, first a summary with profiling information, containing the number of transitions and the number of symbols executed by each process type. Secondly the file contains detailed information about how many times each symbol and each state - input combination is executed.
Example 49 : Profiling Information in Coverage File *************** PROFILING INFORMATION ************** 2 System DemonGame : Transitions = 13, Symbols = 40 3 Block GameBlock 4 Process Main : Transitions = 3 (23%), Symbols = 10 (25%), MaxQ = 2 4 Process Game : Transitions = 6 (46%), Symbols = 15 (37%), MaxQ = 2 3 Block DemonBlock 4 Process Demon : Transitions = 4 (30%), Symbols = 15 (37%), MaxQ = 1This information in Example 49 should be interpreted in the following way:
----------------------------------------------------------------------- Note: To be true, profiling information execution time ought to be mea sured instead of the number of transitions and number of executed symbols, but this information is still very valuable for getting a feel ing for the load distribution. -----------------------------------------------------------------------
Example 50 : Coverage Table in Coverage File
************** COVERAGE TABLE DETAILS **************
2 System DemonGame
3 Block GameBlock
4 Process Main
1 : Start #SDTREF(SDL,main.spr(1),131(30,10),1)
1 : Game_Off Newgame #SDTREF(SDL,main.spr(1),137
1 : Game_On Endgame #SDTREF(SDL,main.spr(1),119(
--------------------
1 START : #SDTREF(SDL,main.spr(1),131(30,10),1)
1 INPUT : #SDTREF(SDL,main.spr(1),137(31,44),1)
1 INPUT : #SDTREF(SDL,main.spr(1),119(56,44),1)
1 NEXTSTATE : #SDTREF(SDL,main.spr(1),134(34,29),
1 CREATE : #SDTREF(SDL,main.spr(1),140(37,59),1)
1 TASK : #SDTREF(SDL,main.spr(1),143(34,72),1)
1 NEXTSTATE : #SDTREF(SDL,main.spr(1),146(35,89),
1 OUTPUT : #SDTREF(SDL,main.spr(1),122(56,59),1)
1 TASK : #SDTREF(SDL,main.spr(1),125(60,72),1)
1 NEXTSTATE : #SDTREF(SDL,main.spr(1),128(59,89),
For each process type two types of information are given, separated by a line of hyphens:
(None)This command will execute all transitions up to but not including the next timer output. The timer output will not be executed even if it is the next transition.
<Time value>The execution of the simulation is resumed. The monitor will become active when the value of the simulation time first becomes equal to the time value given as parameter.
Note that relative time values can be given using the `+' sign. Entering "+5.0" as parameter is interpreted as the time value NOW+5.0. See also "Input and Output of Data Types" on page 1792.
(None)The simulation is terminated. If the command is abbreviated the monitor asks for confirmation. This is the same command as Exit.
<Entry number> <New entry number>This command is used to change the order of signal instances in the input port of the process instance given by the current scope (see the SetScope command for an explanation of scope).
The entry number parameters refer to the numbers assigned by the command ListInputPort. The signal instance with entry number equal to the first parameter will be moved to a position where it in a subsequent ListInputPort command will be assigned the entry number given as the second parameter.
<Entry number> <New entry number>This command is used to change the order in which transitions by process instances are executed. The entry number parameters refer to the entry numbers assigned by the command ListReadyQueue. The process instance with entry number equal to the first parameter will be moved to a position where it in a subsequent ListReadyQueue command will be assigned the entry number given as the second parameter.
The RearrangeReadyQueue command should be used with care when process priorities are used. The ready queue is then sorted in priority order (see also "Scheduling" on page 1967 in the chapter chapter 34, The C Code Generator), which means that a rearrangement might disturb this order. Such a disturbance does not harm, except when a new process should be inserted into the ready queue. In this situation the insert point might not be the proper one. The following insert algorithm is used: Search from the end of the ready queue until a process with higher or equal priority (lower or equal priority value) is found, then insert the new process after the found process. If no process with higher or equal priority is found, then insert the new process first in the ready queue.
<Entry number>This command removes the breakpoint with the specified entry number. The entry number given by ListBreakpoints should be used.
<Entry number>The signal instance with the given entry number in the input port of the process instance given by the current scope is removed (see the SetScope command for an explanation of scope). The entry number given by ListInputPort should be used. If this signal was selected for the next transition, the process instance will execute an implicit nextstate action.
--------------------------------------------------------------------- Note: Entry numbers are just positions in the input port. The removal of a signal changes the entry numbers of the remaining signals. ---------------------------------------------------------------------
<Optional unit name>The GR trace value of the given unit is reset to undefined. If no unit is specified the GR trace value of the system is reset to undefined. As there always has to be a GR trace value defined for the system,
<Optional unit name>The MSC trace value of the given unit is reset to undefined. If no unit is specified the MSC trace value of the system is reset to undefined. As there always has to be a MSC trace value defined for the system,
<Timer name> <Timer parameters>The result of the command is exactly the same as if the process instance given by the current scope had executed a reset action. If the reset action causes a timer signal to be removed and this signal was selected for the next transition, the process instance will execute an implicit nextstate action.
<Optional unit name>The trace value of the given unit is reset to undefined. If no unit is specified the trace value of the system is reset to undefined. As there always has to be a trace value defined for the system, ResetTrace on the system is considered to be equal to setting the trace value to 0. For more information about optional unit names, see the command SetTrace.
(None)This command prints the current scope. See the command SetScope for a description of scope.
<Optional unit name> <Trace value>The GR trace value is assigned to the specified unit (system, block, process, or process instance). If no unit is specified the GR trace value is assigned to the system. The initial GR trace value of the system is 0, i.e. no GR trace, while it is undefined for all other units. For more information about optional unit names, see the command SetTrace.
For a description of the possible GR trace values, see "GR Traces" on page 1830.
<Optional unit name> <Trace value>This command enables the trace of SDL events that take place during the simulation and which can be transformed into events in a Message Sequence Chart. Typically, the events that can be transformed are sending and consumption of signals, and creation and termination of processes.
----------------------------------------------------------------- Note: Setting the MSC trace value with this command does not start the actual logging of MSC events. To do this, the command StartInteractiveMSCLog or StartBatchMSCLog is used. -----------------------------------------------------------------The scope of the trace can be delimited by specifying an optional unit name and a trace value. The general considerations for specifying the unit name for the command SetTrace are also applicable for SetMSCTrace; see page 1819.
------------------------------------------------------------------- Note: Once the logging of Message Sequence Chart traces has been started (using any of the commands StartInteractiveMSCLog or StartBatchMSCLog) modifying the scope of trace may cause unpredictable results, such as Message Sequence Charts with an unexpected appearance. -------------------------------------------------------------------
<PId value> <Optional service name>This command sets the scope to the specified process, at the bottom procedure call. If the process contains services, one of the services can be given as parameter to the command. 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 scope is used for a number of other commands for examining and changing the local properties of a process instance. The scope is automatically set by the execution commands, when entering the monitor, to the next process in turn to execute.
The command Scope prints out the current scope; i.e. the name of the process instance and possibly the service instance and the called procedure instance. See also the commands Stack, Down and Up.
<Timer name> <Timer parameters> <Time value>The result of the command is exactly the same as if the process instance given by the current scope had executed a set action. If the set action causes a timer signal to be removed and this signal was selected for the next transition, the process instance will execute an implicit nextstate action.
<Optional unit name> <Trace value>The trace value is assigned to the specified unit (system, block, process, or process instance). If no unit is specified the trace value is assigned to the system. The initial trace value for the system is 4, while it is undefined for all other units. For a description of the possible trace values, see "Trace Limit Table" on page 1828.
There might, in some cases, be problems in identifying a specific unit. If more than one unit in the system match the, possibly abbreviated, unit name, the first unit found when searched from the system level will be assigned. To make sure the correct unit is assigned, the unit's diagram type, e.g. "process" (unabbreviated), can be introduced before the unit name. If there still are problems, for instance due to the fact that there are several processes with the same name, a qualifier should be inserted immediately before the unit name. An example can be found in "Specifying Unit Names" on page 343.
To specify a PId value, a colon and an instance number must follow directly after the process name; see also "Input and Output of Data Types" on page 1792.
<Entry number>This command is only applicable for symbol breakpoints defined with the command BreakpointAt. The breakpoint with the specified entry number is listed, and the symbol with the breakpoint will be selected in an Editor showing the source GR document. The entry number given by ListBreakpoints should be used.
(None)This command prints the .c file name and line number where the execution of the current SDL transition is suspended. An SDT Text Viewer is opened with the cursor positioned on that line in the C source file. The given line number will reference a statement with the following structure:
XBETWEEN_SYMBOLS(...)The case label just following this statement is the place where the execution will be resumed when an execute command is given in the monitor.
The ShowCLineNumber command is mainly thought to be used when the execution is interrupted within an SDL transition. If the command is issued between two transitions, the XBETWEEN_SYMBOLS statement immediately before the last Nextstate or Stop operation will be referenced in the printout, together with a warning that this is not the current position.
------------------------------------------------------------- Note: Changes made in the monitor, as for example RearrangeReadyQueue, will not affect the printout by this com mand. -------------------------------------------------------------
(None)The symbol in turn to be executed will be selected in an Editor showing the source GR document. If the simulation is not connected to SDT or the SDL source document is in SDL-PR, a GR symbol reference or a PR reference will instead be displayed on the screen. The details about GR symbol references are presented in "Dynamic Errors" on page 1833. A PR reference is a file name and a line number. See also "Syntax" on page 2476 in chapter 41, References in SDT-3.
Note that between the execution of two transitions, i.e. after a Nextstate or Stop operation, no next symbol can be shown. Note also that changes made in the monitor, as for example changing the ready queue using the command RearrangeReadyQueue, will not affect the symbol selected by ShowNextSymbol.
This command uses the same mechanisms to select symbols in the SDL Editor as the GR trace facility, so the same general characteristics as presented in "GR Traces" on page 1830 are also valid for this command.
(None)The last executed symbol will be selected in an Editor displaying the source GR document. If the simulation is not connected to SDT or the SDL source document is in SDL-PR, then a GR symbol reference or a PR reference will instead be displayed on the screen. See the command ShowNextSymbol for more information.
(None)The versions of the C Code Generator and the runtime kernel that generated the currently executing program are presented.
<Unit name> <File name>Starts logging of signals to a specified file. See also the commands CloseSignalLog and ListSignalLog.
The unit name parameter should be either a channel, a signal route, a system, a block, a process type, or a process instance.
(None)The procedure call stack for the PId/service defined by the scope is printed. For each entry in the stack, the type of instance (procedure/process/service), the instance name and the current state is printed. See also the commands SetScope, Down and Up.
<Symbol level> <File name>This command starts the logging of SDL events which can be translated into the corresponding MSC events in a log file (see "Mapping Between SDL and MSC" on page 1831). See also the commands StartInteractiveMSCLog and StopMSCLog.
The results will be stored in a log file, whose contents are specific for this purpose. That log file can later on be read by a Message Sequence Chart Editor, where its contents are interpreted as a Message Sequence Chart and displayed as such.
The symbol level parameter determines if states and actions should be included in the MSC log. For a description of the possible symbol level values, see "Level of Symbol Logging" on page 1832.
The file name parameter to this command can be any valid file name, although it is recommended to use a file name with the suffix .mpr, since this is the default suffix used when reading a log file into a Message Sequence Chart Editor.
(None)When the C Code Generator is used to generate applications, interface functions towards the environment of the SDL system must be provided. The InEnv function, which is used to enter signals into the SDL system, is frequently called from the main loop in the process scheduler. During debugging, the polling of the InEnv function can turned on and turned off.
The StartEnv command turns on the polling of InEnv. At start up of the program polling is turned off. See also the commands StopEnv and CallEnv.
--------------------------------------------------------------- Note: This command and the commands StopEnv and CallEnv are only available when the C Code Generator is used to generate applica tions. ---------------------------------------------------------------
<Symbol level>This command starts the logging of SDL events which can be translated into the corresponding MSC events in a Message Sequence Chart Editor (see "Mapping Between SDL and MSC" on page 1831). See also the commands StartBatchMSCLog and StopMSCLog.
The symbol level parameter determines if states and actions should be included in the MSC log. For a description of the possible symbol level values, see "Level of Symbol Logging" on page 1832.
When the command is issued, the following takes place:
(None)A simulator can communicate with other simulations using SDL signals and the communication mechanism in SDT. Signals sent to the environment in one simulation can enter as signals from the environment in another simulator.
This command is used to tell a simulator to start sending signals that are designated to the environment via the SDT communication mechanism and to start looking for incoming signals (polling) from the SDT communication mechanism. See also the commands StopSDTEnv and CallSDTEnv.
This facility is at program start up turned off, and should only be turned on when a simulator should be able to communicate with other simulators (or applications).
------------------------------------------------------------ Note: The command must be given in both communicating simulators. ------------------------------------------------------------
(None)This command attempts to start the program sdtenv in the SDT start directory. The started program is assumed to connect itself to the SDT communication mechanism and can then communicate with the simulation program.
---------------------------------------------------------- Note: The command StartSDTEnv should be given in the simulation program to make it communicate. ----------------------------------------------------------
<Optional number of statements>This command is used to step statement for statement through SDL transitions. A statement is the same as a symbol, except that a task symbol may contain several assignment statements; compare with the command StepSymbol.
StepStatement will step into procedure calls; compare with the NextStatement command.
After making the step(s) the monitor is entered, making it possible to, for example, examine the temporary status of the actual process instance.
------------------------------------------------------------------- Note: The right hand side of an assignment may contain a value returning procedure call. -------------------------------------------------------------------
<Optional number of symbols>This command is used to step symbol for symbol through SDL transitions. A symbol may contain several statements; compare with the StepStatement command.
StepSymbol will step into procedure calls; compare with the NextSymbol command.
Using the optional parameter, a specified number of symbols can be stepped through. StepSymbol will, however, never step from within one transition into another transition.
After making the step(s) the monitor is entered, making it possible to, for example, examine the temporary status of the actual process instance.
------------------------------------------------ Note: Join is not considered a symbol by this command. ------------------------------------------------
<PId value> <Optional service name>The specified process instance is stopped. If the process contains services, then either the process can be stopped by giving no service parameter, or one of the services can be stopped. The result of the command is exactly the same as if the process instance or service instance had executed a stop action.
(None)This command turns off the polling of the InEnv function; see the StartEnv command for more details.
--------------------------------------------------------------- Note: This command and the commands StartEnv and CallEnv are only available when the C Code Generator is used to generate applica tions. ---------------------------------------------------------------
(None)This command stops the logging of Message Sequence Chart events (in interactive mode as well as in batch mode). In the case of a batch mode logging, the log file will be closed. See the commands StartInteractiveMSCLog and StartBatchMSCLog for more details.
Following this command, it is possible to log the rest of the session on a new file.
(None)The command turns off the communication mechanism described for the StartSDTEnv command.
(None)Moves the scope one step up in the procedure call stack. Up from a service leads to the process containing the service. See also the commands SetScope, Stack and Down.
*** TRANSITION START * PId : Demon:1 * State : Generate * Input : T * Sender : Demon:1 * Now : 1.0000 * OUTPUT of Bump to Game:1 * SET on timer T at 2.0000 *** NEXTSTATE GenerateThe transitions can also be traced in the GR source diagrams. This is discussed in detail under "GR Traces" on page 1830.
When a process instance starts a transition, the trace value that governs the amount of trace to be printed is computed according to the following algorithm:
In the table below the trace limits for all the information that can be part of a trace is presented.
---------------------------------------------------------------- Note: The trace messages are produced when actions defined in the SDL diagrams are executed. These messages are not used when monitor commands like SetTimer, Nextstate, or Stop are entered. ----------------------------------------------------------------
---------------------------------------------------------------
Action Trace
limit
---------------------------------------------------------------
Transition start 2
Parameters of signal in input 6
Output to environment, signal name and receiver 1 (see
below)
Output, signal name and receiver 3
Output caused immediate null transition 5
Parameters of signal in output 6
Task 4
Decision, value of expression in decision 4
Procedure start, procedure return 3
Parameters to procedures 6
Create, successful or unsuccessful 3
Parameters to create 6
Set, timer name, time 3
Time less than Now in set, changed to Now 5
Parameters in set 6
Set caused an implicit reset action 5
Reset, timer name 3
Reset caused timer or signal to be removed 5
Parameters to reset 6
Output of timer signal, timer name, receiver, time 2
Output of timer signal caused a null transition 5
Parameters to timer signal 6
Nextstate, state name 3
Null transitions at a nextstate 5
Parameters to signals in null transitions at nextstate 6
Stop 3
Signals discarded at stop 5
Parameters to signals discarded at stop 6
Timers discarded at stop 5
Parameters to timers discarded at stop 6
Export 4
---------------------------------------------------------------
The trace limit table can be summarized as follows:
-------------------------------------------------------------------------------------
Trace Limit Table Summary
-------------------------------------------------------------------------------------
0 No trace
1 Trace of signals to environment (environment as seen from
the specified unit)
2 Trace of transition start and timer outputs
3 As 2 + trace of important SDL actions
4 As 3 + trace of other SDL actions as well
5 As 4 + result of actions (example: discarded signals)
6 As 5 + Parameters of signals, timers, create actions
-------------------------------------------------------------------------------------
Trace information at trace level 1, i.e. trace of signals sent to the environment of the specified unit, is treated in a special way. This information is not printed if the trace value is greater than 1, instead the normal trace of outputs is used.
The commands associated with GR traces are SetGRTrace, ResetGRTrace and ListGRTraceValues.
The GR tracing will take place in a single SDL Editor window, which will show the appropriate GR diagram as the execution progresses. If no Editor is opened, a new Editor is started.
Three trace values are possible:
The CCITT definition of the MSC language introduces the instance concept. An instance is mapped to any instance of an SDL process.
Assume that we have set the scope of MSC trace to a part of the SDL system, for instance a block and the underlying structure in terms of processes. When an event takes place in the SDL system, one of three possible situations is possible. Let us assume for the sake of simplicity that the event is the sending of a signal from one process to another process. The three cases and their behavior are as follows:
-------------------------------------------------
MSC Trace for MSC Trace for Result
Sender Receiver
-------------------------------------------------
0 No trace
0 1 No trace
2 Conditional trace
0 No trace
1 1 Trace
2 Trace
0 Conditional trace
2 1 Trace
2 Trace
-------------------------------------------------
Example 51 : Dynamic Error Printout Warning in SDL Output of signal Bump Signal sent to NULL, signal discarded Sender: Demon:1 TRANSITION Process : Demon:1 State : Generate Input : T Symbol : #SDTREF(SDL,/usr/tom/demon.spr(1),122(30,55),1) TRACE BACK Process : Demon Block : DemonBlock System : DemongameThe symbol reference given in the TRANSITION message should be interpreted as follows:
-------------------------------------------------------------------
Item Text in Interpretation
Example 51
-------------------------------------------------------------------
1 SDL Reference to SDL-GR object
2 /usr/tom/de Reference to the file
mon.spr
3 (1) Page name
4 122 The object identity (an unique number
assigned by the SDL Editor)
5 30 The x-coordinate of the object in mm. The ori
gin of coordinates is the upper left corner of
the page.
6 55 The y-coordinate of the object in mm
7 1 Line number within symbol
-------------------------------------------------------------------
By entering the monitor command ShowPreviousSymbol, the symbol that caused the error is displayed.For more information on references in SDT, see chapter 41, References in SDT-3.
Error in SDL array index in sort <sort>: <value> is out of range.Violation of the index range given in an array.
Error in assignment in sort <sort>: <value> is out of range.Violation of the range conditions given in a syntype.
Error in SDL Decision: Value is <value> Entering decision error stateThe value of the expression in the decision did not match any of the possibilities (answers).
Error in SDL Import. Attempt to import from NULL Error in SDL Import. Attempt to import from stopped process instance Error in SDL Import. Attempt to import from the environment Error in SDL Import. No process exports this variable Error in SDL Import. The specified process does not export this variableError in an import statement. Supplementary information about remote variable and exporting processes is also given.
Warning in SDL Output of signal <signal>. No path to receiver, signal discardedAn attempt was made to output a signal to a PId expression. There exists, however, no path of channels and signal routes between the sender and the receiver that can convey the signal.
Warning in SDL Output of signal <signal>. No possible receiver found, signal discardedAn attempt was made to output a signal without specifying a to PId expression. When all paths or all paths mentioned in a via clause had been examined no possible receiver was found.
Warning in SDL Output of signal <signal>. Signal sent to NULL, signal discardedAn attempt was made to output a signal to a PId expression that was null.
Warning in SDL Output of signal <signal>. Signal sent to stopped process instanceAn attempt was made to output a signal to a PId expression that referred to a process instance which has performed a stop action.
Error in SDL View. Attempt to view from NULL Error in SDL View. Attempt to view from stopped process instance Error in SDL View. Attempt to view from the environment Error in SDL View: The specified process does not reveal this variable Error in SDL View: No process reveals this variableError in a view statement. Supplementary information about viewed variable and viewing process is also given.
Error in SDL Create: Process <process> More static instances then maximum number of instances.Obvious!
Error in SDL Operator: Extract! in sort Charstring, Index out of bounds Error in SDL Operator: Modify! in sort Charstring, Character NUL not allowed. Error in SDL Operator: MkString in sort Charstring, Character NUL not allowed. Error in SDL Operator: First in sort Charstring, Charstring length is 0 Error in SDL Operator: Fix in sort Integer, Integer overflow Error in SDL Operator: Last in sort Charstring, Charstring length is 0 Error in SDL Operator: Substring in sort Charstring, Charstring length is 0 Error in SDL Operator: Substring in sort Charstring, Length of substring <= 0 Error in SDL Operator: Substring in sort Charstring, Start index is <= 0 Error in SDL Operator: Substring in sort Charstring, Start index + length of substring > length of charstring Error in SDL Operator: / in sort Integer, Attempt to divide by 0. Error in SDL Operator: / in sort Real, Attempt to divide by 0.0. Error in SDL Operator: Rem in sort Integer, Second operand is 0 Error in SDL Operator: Mod in sort Integer, Second operand is 0
Example 52 : Assertion in C Code
TASK '' /*#CODE
#ifdef XASSERT
if (#(I) < #(K))
xAssertError("I is less than K");
#endif
*/ ;
The xAssertError function, which has the following prototype:
extern void xAssertError ( char *Descr )takes a string describing the assertion as parameter and will produce an SDL run-time error similar to the normal run-time errors. The function is only available if the compilation switch XASSERT is defined. For the standard libraries this is true for all libraries except the Application Library.
Decision with ANY 1 2 3 Enter path :At this point, the user must enter a path value (integer) within the allowed range. If GR trace is enabled, the user may enter a path value followed by a `?' to see the corresponding path in an SDL Editor.
Informal decision: `Question1' `answer1' 1 `answer2' 2 `ELSE' 3 Enter path :At this point, the user must enter a path value (integer) within the allowed range. If GR trace is enabled, the user may enter a path value followed by a `?' to see the corresponding path in an SDL Editor.
Operator op in sort s is called Parameter 1: 50 Enter value(s) :At this point, the user must enter a value in the resulting sort to be the returned value of the operator when called with the listed parameter values.
Next Chapter