![]() |
![]() |
![]() |
![]() |
![]() |
The SDL Target Tester - An Overview
Prerequisites
The SDL Target Tester is an optional part of the Cmicro Package and is delivered when specifically ordered. It is an addition to the Cmicro Library and contains the following parts:
- the host tool chain (see Using the SDL Target Tester's Host)
- the target library (see The Target Library)
The SDL Target Tester's host executable is a tool chain which consists of the executables sdtmt, sdtmtui, sdtmpm and sdtgate and sockgate. The sdtgate module contains the V.24 and sockgate the TCP/IP implementation for connecting host and target. All open interface functionality is utilized here.
The target library is mandatory when the SDL Target Tester is ordered. It must be used together with the Cmicro Library on the target. By using the open interface, it is possible to connect user specific tools to the SDL Target Tester's target library.
This diagram gives an overview of the SDL Target Tester functionality:
The following components, as seen from the user's point of view, represent the SDL Target Tester:
- The Cmicro Tracer - trace of SDL and system events.
- The Cmicro Recorder - recording and replaying SDL sessions.
- The command and debug interface.
The Cmicro Tracer is introduced in the subsection Following the Execution Flow - The Cmicro Tracer.
The Cmicro Recorder is introduced following the subsection Reproduction of Errors - The Cmicro Recorder.
The command and debug interface is introduced in the subsection Commands for the Host and Debugging Facilities.
The following subsections give an overview of how to use the SDL Target Tester. A detailed description of the necessary preparations and adaptations will be given in the sections itself.
- Using the SDL Target Tester's Host"
- Graphical User Interface
- The Target Library
- Connection of Host and Target
- More Technical Descriptions.
These sections follow after the introduction subsections.
Following the Execution Flow - The Cmicro Tracer
General
The Cmicro Tracer transmits information about the execution flow of the SDL system on the target. Information traced includes the signals sent and received by processes and the SDL states and symbols entered in execution flow. A filter can be defined so that only partial trace information is created for particular process instances or for particular SDL constructs. The tracer can be connected with the MSC Editor on the host, thus allowing observation of dynamic signal trace between processes in the system or from the environment to the system on the target.
Tracing SDL Events
The following SDL events can be traced.
Used at system start, appears for each statically created process
For each symbol in each process in the system the trace can be separately switched on or off.
Please consult the subsection The API on Target for information about how to set the different options.
Tracing Other Events
The following system events can be traced.
Each system event can be separately switched on or off.
Please consult the subsection The API on Target for information about how to set the different options.
Display of Traces in the MSC Editor
By using the SDL Target Tester, it is possible to create Message Sequence Charts with the MSC Editor. Two modes are of special interest:
The first case, however, only makes sense if the host has enough time to handle and display all the traces created during the run-time of the SDL system. Alternatively there might be SDL systems which do not have these timing constraints. For example, the SDL system may wait until the MSC trace is completed.
The second possibility does not need that much processor power on the host site. In practice, this method is more useful.
The method with using the Cmicro Recorder is the one with the best real-time properties. In comparison to the trace, the Cmicro Recorder stores only a reduced subset of information in a compact format.
Reproduction of Errors - The Cmicro Recorder
The SDL Target Tester's Record and Play functions are only available if a Cmicro Recorder license is available.
General
Using the Cmicro Recorder, the user can "record" the actions taken within an SDL system running on the target and save these to a file on the host machine. This file can later be "played" in order to run the system through the same state changes, so that the same actions are performed. In this way error situations, perhaps recorded by a client or a developer at another location, can be reproduced. In the following, a general description is given. A more detailed description of the internal procedures can be found in the subsection "Type and Amount of Stored Information". The subsection "General Restrictions on Record and Play"may also provide more information about how it works.
Recording an SDL Session
Use of the Cmicro Recorder makes sense whenever an SDL system is executed in real-time on the target in combination with a host.
The amount of information transferred via the communications link and stored into a file on the hard disk is kept small and compact, so that the real-time properties are not influenced. Only information is stored, which is necessary in order to replay an SDL session later. It is the communication of the environment to the SDL system, and the expiration of timers, which is recorded.
It is not possible to receive information about the inner events of the recorded SDL system, by using the recorder only. The purpose of the Cmicro Recorder has nothing to do with the purpose of the Cmicro Tracer. The user also has to use the Cmicro Tracer if he wants to get information about internal events. Additional information is then transmitted via the communications link and stored into a file which can be displayed dynamically or later on. The performance of the communications link dictates whether real-time trace is possible. The more information traced via the link, the higher the performance should be.
The record mode must be switched on within the target (by using the C function interface on target), and on the host - see subsection Record a Session).
Re-Playing an SDL Session
After producing a file with the record mode, the file can be replayed in order to run the SDL system in the same order through the same system states.
When the end of file is reached which is indicated with <Play mode off> to the target, the SDL system is able to react on ordinary environment signals coming from the real environment (if programmed by the user).
The play mode must be switched on within the target by using the SDL Target Tester Command Recorder-Play. No environment signals may be handled by the user in the C function xInEnv during the play.
Reaching the Erroneous System State
Sometimes, when a file is replayed, the erroneous situation can directly be viewed at another device, i.e. if the SDL system runs in an emulator with breakpoints set, or if there is, for instance, an LC display connected to the SDL environment.
In this case, it is not necessary to compare output files. In other cases, it might be of interest to do so as described later.
Comparing the Results
A comparison of two executions is possible, when two files containing the same type and amount of information are compared.
The procedure goes as follows:
- Change the format from binary into ASCII for both files (command Convert-File).
- Use UNIX diff or an ASCII editor with options in order to evaluate the differences.
Commands for the Host and Debugging Facilities
The command interface and the debugging facilities are very helpful in finding errors produced within the target.
For instance, after an SDL interpretation error has occurred, it is possible to suspend the SDL system and to inspect the global state by viewing the signal queue(s). After the queue size has been re-dimensioned, the queue can be inspected again on the host site during a target execution.
There are several commands to check that timers are correctly processed.
The ability to set breakpoints during real-time execution and to execute a single step also helps to find an error situation.
The amount of trace information can dynamically be defined via commands. A differentiation is made between the information on the communications link and the information displayed.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |