![]() |
![]() |
![]() |
![]() |
![]() |
Using TTCN Link
The phases involved when you are using TTCN Link - Preparing for the Generation of Declarations, Generating the Declarations and Creating Test Cases - will be described below. You can also read about Showing SDL System Information and Merging TTCN Test Suites in the TTCN Suite.
Preparing for the Generation of Declarations
Before it is possible to generate the declarations, you have to do two things:
- Adapt the SDL system to the requirements of test generation and TTCN Link.
- Generate a Link executable for the SDL specification.
Adapting the SDL System
The major adaptation of the SDL system that you have to do, is to modify it to properly describe the test architecture that is to be used. Basically, the requirement is that the channels from/to the environment of the system must correspond to the points of control and observation in the test suite. For example, the SDL system might be a specification of a communication protocol where the lower side of the protocol in practise can only be accessed through a network. To be able to create correct test cases, you also have to include the communication media in the SDL specification. Note however, that the specification of the media does not have to be a detailed specification of the functionality, only a specification of the aspects relevant to the current testing situation.
Generating a Link Executable
Once the SDL specification describing the system to be tested and the test architecture are finished, you can generate a Link executable. (A Link executable is sometimes also referred to as state space generator.) You do this in the same way as when you generate an SDL Simulator or Explorer.
To generate a Link executable:
- Select Make from the Generate menu in the Organizer.
- Select Analyze & generate code.
- Select Generate Makefile.
- Select Use Standard Kernel and TTCN Link.
- If necessary, change other options.
- Click Full Make.
You should not change the SDL system after you have generated the Link executable. Such changes will not affect the generated Link executable and therefore not affect the generation of declarations.
Generating the Declarations
There are two steps involved in generation of the declarations (and the default table):
Specifying the Link Executable
Before the actual generation of the TTCN declarations, you have to specify the Link executable - and thereby the SDL system - to use. There are two methods for doing this: associating the SDL and TTCN systems in the Organizer and explicitly selecting the Link executable in the TTCN Suite. In case a Link executable has been specified both in the Organizer and in the TTCN Suite, the one selected in the TTCN Suite is the executable that will be used.
Also note that the TTCN test suite that you are going to generate the declarations in, have to be created and added to the Organizer (and the same system file as the SDL system is included in).
Associating the SDL System with the TTCN Test Suite in the Organizer
- In the Organizer, select the SDL system (the top node).
- Select Associate from the Edit menu.
- In the dialog, select the TTCN test suite and click OK.
Selecting the Link Executable in the TTCN Suite
- Make sure that the test suite is opened and that the Browser is active.
- From the SDT Link menu point to Select Link Executable. On UNIX, it is the menu in the Browser.
- In the dialog, select the Link executable and click OK.
The SDL system from which the Link executable is generated may contain external synonyms that do not have a corresponding macro definition (see External Synonyms). Such an SDL system cannot be used with TTCN Link and you will get an error message when trying to select the Link executable.
However, if you set the environment variable SDTEXTSYNFILE to a synonym definition file before starting SDL Suite or TTCN Suite, this file will automatically be used to define the external synonyms. 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.
Generating the TTCN Declarations
When you have specified the Link executable, you can generate the declarations in the TTCN Suite:
- Select Generate Declarations from the SDT Link menu. On UNIX, it is the menu in the Browser.
- Expand the Declarations Part and take a look:
- One or more PCO type declarations have been generated.
- For each channel to/from the environment in the SDL system, one PCO declaration has been generated.
- For each signal on these channels, one ASN.1 ASP/PDU declaration has been generated.
- For each data type that is used as a parameter on the signals to/from environment, a TTCN/ASN.1 data type definition has been generated if the data type cannot be mapped to a standard TTCN data type.
- Expand the Dynamic Part. You should see that a default behavior tree called Otherwise Fail is generated. This contains otherwise statements with verdict FAIL for all generated PCOs.
PCO Mapping
There are two alternatives available for generation of the PCO types: either one PCO type is generated for each channel in the SDL system or only one PCO type is generated. This is defined by the configuration command define-pco-type-mapping (see PCO Type Generation Strategy). The default is that only one PCO type is generated.
If more than one PCO type is generated, they are named <ChannelName>_TypeId. If only one PCO type is generated it is called PCO_Type.
ASP/PDU Mapping
The generated ASPs/PDUs are given the same name as the corresponding SDL signal with one exception: If there are multiple PCO types and there is one signal that can be transported on more than one channel to the environment, this signal is divided into two ASPs, since an ASP may only be associated with one PCO type. The ASPs are then given names like <SDLSignalName>_<PCOName>.
By default, ASPs are generated from the SDL signals. However, you can change it to PDUs by using the define-signal-mapping command (see SDL Signal Mapping Strategy).
Data Type Mapping
The data type mapping from SDL to TTCN/ASN.1 is defined in the following table. In most cases a table containing an ASN.1 type definition is generated for each data type. In the table below, this is indicated by a "<TTCN name> -> <ASN.1 definition>" clause. The <TTCN name> is the name used to denote the type in the test suite and the <ASN.1 definition> is the ASN.1 type definition that is the contents of the generated table. If the TTCN name is omitted, the name is given by the name of the corresponding SDL data type.
In addition to the data types above, data types defined in external ASN.1 modules can also be used. These data types are mapped to definitions in the table named "ASN.1 Type Definitions by Reference" in the test suite. For each data type in the external ASN.1 module that is used on signals to/from the environment, one line defining the data type will be generated in this table. Note that the Generate Declarations command in the SDT Link menu assumes that the external ASN.1 module is setup as a dependency of the TTCN document.
No other data types than the ones mentioned above may occur on signals to/from the environment in the system.
Note that SDL is not case sensitive whereas TTCN is case sensitive. The spelling of the names generated by TTCN Link is given by the defining occurrence of the corresponding SDL name. Also note that no transformation of names is performed during generation of the TTCN names. This may in some cases lead to incorrect TTCN names if for example a reserved word from TTCN is used in the SDL system. To fix this problem, you have to change the name in the SDL system to a legal TTCN name.
Note that the SDL character NUL is mapped to NUL. Unfortunately, NUL is not an IA5String allowed character. So this must manually be changed to a legal character, e.g. "". The NUL character is especially interesting since un-initialized SDL characters are set to NUL.
Modifying the Generated Declarations
In some cases, you may find it useful to manually modify the declarations that have been generated by TTCN Link before continuing with the development of the test cases. There are in particular two interesting cases:
- ASPs vs. PDUs.
- TTCN Link automatically generates ASPs for all signals visible on the border of the SDL system unless defined otherwise by the define-signal-mapping option (see SDL Signal Mapping Strategy). If PDU definitions are more suitable for some of the signals, this is the time to change them. The simplest way is to copy the generated ASPs from the section ASN.1 ASP Type Definitions and paste them as PDUs in the section ASN.1 PDU Type Definitions.
- ASP field names.
- The ASPs are generated based on the SDL signals, and since the signals in SDL have no parameter names (only types), TTCN Link automatically generates names for the ASP fields. The fields are given the name "<type name><no>" where the <type name> is the name of the type of this parameter (but always starting with a non-capital letter to follow ASN.1 rules). It is however possible to change these names in the generated definitions, and if you do it before the test cases are developed, the new manually defined names will also be used in the test cases.
Regeneration of Declarations
It is possible to regenerate the declarations from an SDL system to incorporate new signals, channels and/or data type into the test suite. If you select Generate Declarations from the SDT Link menu again, only declarations with a name different from the existing test suite declarations will be inserted into the test suite.
Creating Test Cases
To create test cases with TTCN Link, you use the Table Editor in the TTCN Suite. When TTCN Link is used, the test cases are synchronized, that is, verified against the SDL specification.
In synchronized mode, the test case is guaranteed to be consistent with the specification. Each action you perform during the development of the test case will be incrementally verified by the state space exploration part of TTCN Link. When a table is in synchronized mode, the SDT Link menu of the UNIX Table Editor will contain new menu choices for editing of the test case. In Windows, you can find the corresponding commands in the Link dialog:
- Send will add a send statement to the test case. This is a manual step where you define the constraint to be associated with the send statement.
- Receive automatically generates all valid responses from the system under test. This implies that you do not need to check with the specification which possible signals the system can send in the state it is driven to by the proceeding lines in the test case.
- Start timer and Cancel timer are also manual commands where TTCN timers are started and cancelled. However, note that the timeout event corresponding to the timer will be automatically generated as a result of a Receive command.
- Attach test step will attach a previously defined test step, while still keeping the editor in synchronized mode.
If you modify the contents of the test case by using other menu choices, the editor will leave the synchronized mode.
The verdict for the generated test case lines, will always be either PASS or INCONCLUSIVE since the generated receive lines will always correspond to valid behaviors of the implementation under test.
A default test step, which consists of an otherwise fail for each PCO, will ensure that an incorrect response from the implementation under test always will give a FAIL verdict as a result from the test case.
Constraint Restrictions
The constraints that are used in send and receive statements in the test cases, are subject to certain restrictions:
- They may not use test suite or test case variables or test suite parameters.
- They must be "exactly" defined without any omits, any values, ranges, wildcards, etc.
The following is however allowed in send and receive constraints a test case is resynchronized, even though it is not generated automatically for receive constraints:
- The constraints can be structured/chained, that is, the constraints can reference and use other constraints defined in the test suite.
- The constraints can use test suite constants.
- The constraints can be parametrized.
Creating Test Steps
It is often useful to structure the test case into test steps. To do this by using TTCN Link:
- Create the TTCN statements that should be in the test step directly in the test case table. This should of course be done in synchronized mode.
- Cut the lines that should form the test step from the test case.
- Create a test step table.
- Paste the lines into the new test step table and adjust the indentation level.
- Add an attach statement to the test case.
Showing SDL System Information
When you use TTCN Link for creating a test case, it is possible to access the SDL specification from the Table Editor.
To do this you first select a line in the test case. Then you have three alternatives:
- Select Show SDL from the SDT Link menu.
- Select Show Coverage from the SDT Link menu.
- Select Show MSC from the SDT Link menu.
Merging TTCN Test Suites in the TTCN Suite
By using TTCN Link, you can only generate the declarations and create the dynamic tables. Either you could add the constraints and dynamic tables manually or merge the TTCN Link generated test suite with one generated by Autolink. A test suite generated by Autolink is in TTCN-MP format and contains constraints, declarations and dynamic tables.
- Make sure that the test suite that you want to merge the MP file into - that is, the destination document - is opened and active.
- In Windows, select Autolink Merge from the File menu.
- Find and select the MP file that you want to merge with the currently opened test suite.
- Click OK (in Windows) or Merge (on UNIX).
The merge will only work if the two test suites do not conflict. A conflict occurs if any TTCN object in the MP file has the same name as any TTCN object in the destination document. However, if such a conflict is detected, the merge will continue but the conflicting object in the MP file will be skipped.
Constraints will be merged in a special way. For example, the MP file may contain a TTCN ASP constraint called constraint1 that refers to the type type1 which is of the incompatible type TTCN PDU TypeDef. Because of this, a copy of constraint1 will be inserted as a TTCN PDU constraint instead. However, this "type conversion" is limited. An ASN.1 constraint will not be converted to a TTCN constraint or vice versa.
Summary of TTCN Link
TTCN Link supports test case development and there are two major objectives:
- To help solving the consistency problem that arises as soon as there are two different descriptions of the same system, in this case the SDL specification and the TTCN test suite.
- To supply an environment that, based on the SDL specification, supports test suite development during the TTCN design. Both by directly using the SDL specification, for example to generate the declarations, and by providing access to the SDL specification directly from the TTCN Suite.
Overview of the TTCN Link Algorithm
This section will give a brief introduction to the algorithm used by TTCN Link to synchronize a test case with an SDL system.
The Composed System
The system that TTCN Link analyzes is the composed system that consists of both the SDL specification and the TTCN test case that is interactively created.
The connection between the SDL system and the TTCN test case is created by connection of the channels to/from environment in the SDL system to the PCOs in the test suite.
State Space Exploration
The technique used by TTCN Link is based on state space exploration (sometimes referred to as reachability analysis) of the system composed of the SDL system together with the test case that is being created. The state space of this system can be viewed as a graph, where the nodes represent system states and the edges represent actions that can be performed by the system.
Each system state represents the combined system in one moment in time. It contains information of for example:
- What SDL process instances exist
- The variable values of all the process instances
- The control flow state of the instances
- Any procedure calls, including local variables in the procedures
- The current line number of the test case
- Any started timers, both SDL and TTCN timers
The actions represented by the edges are either SDL actions like input, output, tasks, etc., or TTCN actions like send, receive or start timer.
Essentially, the algorithm to generate the state space of the combined system is the following, where two global variables - StateSpace (a graph that will contain the state space of the system) and TreatList (a list of states that is yet to be treated by the algorithm) - are used:
- Create the start system state and add it to StateSpace and TreatList.
- Remove one state (in step 3-4 called the current state) from TreatList.
- Compute all possible actions that can be performed in the current state and the resulting system state that will be reached when the respective action has been performed.
- For each action/resulting state:
- If TreatList is empty: Terminate algorithm, the state space of the system is now represented by the graph in StateSpace.
Incremental State Space Exploration
Since you interactively create the test case that describes the TTCN part of the combined SDL/TTCN system, it is not possible for TTCN Link to compute the entire state space at once. Instead, the state space exploration is performed in an incremental fashion in the following way:
- You compute the state space that can be reached without any action by the test case.
- When you TTCN Link to add a TTCN statement to a leaf in the test tree, you add the corresponding TTCN action(s)/resulting system state(s) to the state space.
- Generate the state space that can be reached from the newly created system state(s) without any further action by the test case.
- Go to step 2.
The consequence of this algorithm is that the state space of the combined SDL/TTCN system is explored in an incremental fashion, where each increment corresponds to a command you have given. Also the structure of the state space is influenced by the incremental way that it is generated. The state space can be visualized as a tree structure, where each node represents one line in the test case and a subpart of the state space, to be more precise, the subpart of the state space where the test case has executed this particular line but not the next one.
Since each line in the test case is created by a command from you, each node with its associated part of the state space can also be viewed as the state space increment that was created by a specific command.
Random Walk Exploration
The default state space exploration algorithm used by TTCN Link is the algorithm described in the previous sections. This is usually referred to as exhaustive exploration since it exhaustively explores the state space until all reachable states has been generated. The benefit of this algorithm is that when the exploration is finished, you can be sure that all possible combinations and alternatives are explored, that is, if TTCN Link generates two alternatives in a receive statement, the algorithm guarantees that there are no more valid alternatives. However, the drawback is that the algorithm requires all states in the state space to be kept in primary memory. For large SDL systems this may not always be possible with the computers available. The response time may also be unacceptable for interactive work with large systems.
To be able to use TTCN Link even in these cases, a second exploration algorithm is also provided. This is the random walk algorithm that, instead of exploring the entire state space, explores random paths in the state space using the algorithm described below. The input to the algorithm is a set of start states called StartList and a maximum depth of the exploration (MaxDepth) and the number of repetitions (Rep):
- Select one state (in step 2-4 called the current state) from StartList.
- Compute all possible actions that can be performed in the current state and the resulting system states that will be reached when the respective action has been performed.
- If no actions could be performed from the current state or if the depth of the current random walk is MaxDepth, the current random walk is pruned. If the number of random walks performed so far is less than Rep, go to step 1, otherwise terminate the algorithm.
- If actions could be performed and the depth is less than MaxDepth, select one of the generated states as a new current state and go to step 2.
The benefit with the random walk algorithm is that not more than a few system states (the current state and its successors) need to be kept in the memory at the time. The drawback is that there is no guarantee that the entire state space is explored, so, for example, even if TTCN Link generates only one receive alternative, it is possible that there are more alternatives.
To accomplish the best, both from exhaustive exploration and random walk, a two-step approach can be used when you use TTCN Link for large SDL systems:
- Develop the test cases interactively by using the random walk algorithm with a small number of repetitions (1-3).
- Verify that no more receive alternatives were possible by resynchronizing the test cases and using the exhaustive exploration algorithm. Or, if this is not possible due to lack of memory, use random walk with a high number of repetitions (at least 10, preferably 50-100).
This strategy gives both good performance when you interactively create the test cases and a good verification of the correctness of the test case during the automatic resynchronize. The execution time of the random walk algorithm is proportional to the number of repetitions.
You select which algorithm to use in the .linkinit file (on UNIX) or the linkinit.com file (in Windows) by using the
define-algorithm command as described in section Configuring the TTCN Link Executable.Summary of the TTCN Link Algorithm
The algorithm used by TTCN Link to resynchronize a TTCN test case with an SDL system, is based on an incremental state space exploration of the state space of the composed system. The system consists of the SDL specification, together with the test case under construction. In the state space exploration, each command that you give will cause a new part of the state space to be explored, that is, the part that corresponds to the TTCN statement line that is inserted by the command. Two different exploration algorithms are available: exhaustive exploration and random walk. Exhaustive exploration is used for interactive development of test cases for a small SDL system and for verification of test cases for large systems. Random walk is used for interactive development of test cases for large SDL systems.
Configuring the TTCN Link Executable
This section describes the various options that can be used to configure the Link executable. You can change the options by giving the corresponding commands in a file called .linkinit (on UNIX) or linkinit.com (in Windows) in the target directory. The options that can be set are:
- Exploration Algorithm
- Random Walk Depth
- Random Walk Repetitions
- PCO Type Generation Strategy
- SDL Signal Mapping Strategy
- Stable State
- Timer Mode
- Transition
- Scheduling
- MSC Trace
These options will be described below.
It is also possible to add user-defined rules to the .linkinit file (on UNIX) or the linkinit.com file (in Windows) in order to prune the state space that is explored by Link. The user-defined rules are described in User-Defined Rules.
Exploration Algorithm
What exploration algorithm is used, is defined by the command
define-algorithm [exhaustive|randomwalk]and has the default value exhaustive. The differences between the different algorithms are described in section Overview of the TTCN Link Algorithm.
Random Walk Depth
The maximum depth of each random walk is defined by the command
define-randomwalk-depth <integer>and has the default value 500.
Random Walk Repetitions
The number of times a random walk is performed when a state space is explored by using this algorithm is defined by the command
define-randomwalk-repetitions <integer>PCO Type Generation Strategy
The PCO Type generation strategy is defined by the command
define-pco-type-mapping [system|channel]
- If the parameter given is system then only one PCO type is generated for the entire system.
- If the parameter is channel then one PCO type is generated for each channel to/from the environment.
The choice also has an impact on the ASPs that are generated from SDL signals. Usually the name of the ASP is the same as the name of the SDL signal. However, if one PCO type is generated for each channel to/from the environment and one SDL signal can appear on more than one of these channels, then one ASP is generated for each channel it appears on. This is needed since an ASP can only be associated with one PCO type. The names of the signals are in this case defined as <signal name>_<channel name>.
SDL Signal Mapping Strategy
The SDL signals that appear on channels to/from the environment in the SDL system are either mapped to ASN.1 PDU or ASN.1 ASP definitions in the test suite. The mapping is defined by the command
define-signal-mapping [asp|pdu]Stable State
The stable state option is defined by the command
define-stable [on|off]Consider the situation when an empty test case has been resynchronized. The Link executable will now have computed the state space that can be reached without any input from or output to the tester. Usually, the state space looks something like this:
where 0 is the start state, 1-4 are intermediate states and 5 is a stable state where all internal queues in the SDL system are empty and nothing more can happen without any input from the tester.
Let us now give a send command. This implies that new states are created as send transitions are added to the state space.
If the stable state assumption is off then we add one send transition to each state in the original state space, the new state space looks something like this:
where all states called something with `a' are new. Now the states space that contains states that can be reached from the `a' states without any input from or output to the tester is explored.
On the other hand, if the stable state assumption is on then we only add a send transition to the stable state, giving a new state space looking like:
Now, only the states that can be reached from "5a" without any input from or output to the tester are explored. This state space is of course a lot smaller that the one above.
Timer Mode
This is an option that in most cases will not have to be changed. The option defines how to interpret timeout actions compared with all other actions in the system. The option is changed by the command:
define-timer-mode [long|short]If the timer mode is long, timeout actions will never occur if there is an internal event possible in the system. Essentially, the assumption is that the performance of the test system and IUT is good enough to ensure that the execution time for the actions are very small compared to the timeout times. Consider a system with the following state space when the long timer mode is used:
In this system, the timeout event does not occur until no other event can happen. The transition leading to states 1-3 are all usual transitions - for example. inputs and outputs - so the timeout will only occur in state 3, where no other event is possible.
If the timer mode would have been short, the state space would have looked differently:
The reason is that the timeout event now is possible in all the states 0-3.
Transition
The transition option defines what is considered to be an atomic transition in the state space and is defined by the command:
define-transition [`sdl'|'symbol']If the transition option is set to sdl, then SDL process graph transitions are considered atomic. This means that there will be no states in the state space where SDL processes are in the middle of a process graph transition. In all system states in the state space, the processes will always be in a process graph state.
If the transition option is set to symbol, the SDL process graph transitions are not considered to be atomic. In theory, this would imply that the processes could be interrupted anywhere during the execution of a transition. However, it turns out that for test generation purposes it is enough if the process graph transitions are divided at the points where one process communicates with another process, for example after an output or a create. A sequence of tasks or decisions is still viewed as atomic.
The consequence of this is that there will be more transitions in the state space if the transition option is symbol than if it is sdl. Consider a simple system with only one process. Let this process have a transition like:
state xx;input st1;output sig2;output sig3;output sig4nextstate st2;If the transition option is sdl, there will only be one transition in the state space that corresponds to the process graph transition above:
X : process is in state st1|Y : process is in state st2If the transition option is symbol, there will be a sequence of transitions in the state space:
X : process is in state st1| input st1; output sig2;X1| output sig2;X2| output sig3;X3| output sig4; nextstate st2;Y : process is in state st2This will of course give a lot bigger state space.
Scheduling
The scheduling option is defined by the command
define-scheduling [`first'|'all']This option controls how many processes are allowed to execute in a given system state. If the option is set to first, only one process (the first in the ready queue) is allowed to execute. If the option is set to all, all processes that can execute are allowed to do it. The default value is all.
Consider an SDL system with two static processes. If the scheduling option is all, the initial part of the state space for this system will probably look like:
- 0 is the initial state (both processes are in the start symbol).
- 1 is the state where the first process has executed its start transition while the second process is still in its start symbol.
- 2 is the state where the second process has executed its start transition while the first process is still in its start symbol.
- 3 is the state where both processes have executed their start transitions.
On the other hand, if the scheduling option is first, it will look like:
- 0 is the initial state (both processes are in the start symbol).
- 1 is the state where the first process has executed its start transition while the second process is still in its start symbol.
- 2 is the state where both processes have executed their start transitions.
If there are lots of processes, there will be a significant difference in the size of the state space depending on how the scheduling option is set!
MSC Trace
The MSC trace options control what is displayed in the MSCs generated by TTCN Link. There are two different MSC trace options controlling if states and actions in the SDL system are showed as MSC condition symbols and MSC action symbols. The options are set by the following commands:
define-MSC-trace-actions [ `on' | `off' ]define-MSC-trace-states [ `on' | `off' ]The default value for both options is `off'.
An Example of a .linkinit / linkinit.com File
This following .linkinit file (on UNIX) or linkinit.com file (in Windows) will change the exploration algorithm to random walk and set the number of repetitions to 2:
define-algorithm randomdefine-random-rep 2This is a useful configuration when you work interactively with TTCN Link, since the random walk algorithm is quicker and requires less memory than the exhaustive algorithm. But, since the random walk in some cases can miss some alternative receive statement, a useful strategy is the following: Use the configuration above when you work interactively with TTCN Link. However, when you have finished with a test case or a number of test cases, check that the assumptions are valid by resynchronizing with the exhaustive algorithm or a larger number of repetitions.
Note that in the commands in the .linkinit file (on UNIX) and the linkinit.com file (in Windows) can be abbreviated as long as they are unique.
User-Defined Rules
User-defined rules can be used during state space exploration to prune the search performed by the TTCN Link. Whenever a system state is found that matches the defined rule, the search is pruned at this particular state. This can be useful in order to remove specific exceptional behavior from the test cases that are designed and instead handle these in a special default test step.
Consider an SDL specification that contains a clock process that has a timer intervaltimeout. Every time the intervaltimeout expires, a signal DisplayTime is sent to the environment of the SDL system. Since this can happen at any time during the execution, there will be an alternative at all receive statements corresponding to the reception of this signal. To avoid this, it is better to add a receive statement in the default dynamic behaviour that skips this signal.
To achieve this with TTCN Link, you have to do two things:
- Define a rule that prunes the state space at appropriate places.
- Modify the default dynamic behaviour that is generated by TTCN Link.
A rule that prunes the state space whenever the intervaltimer expires is the following:
def-rule sitype(signal(clock:1))=intervaltimeout;The statements that need to be added to the default behaviour are:
PCO?DisplayTime DisplayTime_Match_AllRETURNThese lines will cause the tester to ignore DisplayTime signals sent from the system.
A rule essentially gives the possibility to define predicates which describe properties of one particular system state. As soon as this predicate matches a system state, TTCN Link will prune the search. A rule consists of a predicate (as described below) followed by a semicolon (`;'). In a rule, all identifiers and reserved words can be abbreviated as long as they are unique.
Only one rule can be used at any moment. If more than one rule is needed, reformulate the rules as one rule, by using the boolean operators described below.
Predicates
The following types of predicates exist:
- Quantifiers over process instances and signals in input ports
- Boolean operator predicates such as "and", "not" and "or"
- Relational operator predicates such as "=" and ">"
Parenthesis are allowed to group predicates.
Quantifiers
The quantifiers listed below are used to define rule variables denoting process instances or signals. The rule variables can be used in process or signal functions described later in this section.
exists <RULE VARIABLE> [: <PROCESS TYPE>]
[ | <PREDICATE>]This predicate is true if there exists a process instance (of the specified type) for which the specified predicate is true. Both the process type and the predicate can be excluded. If the process type is excluded, all process instances are checked. If the predicate is excluded, it is considered to be true.
all <RULE VARIABLE> [ : <PROCESS TYPE>]
[ | <PREDICATE>]This predicate is true for all process instances (of the specified type) for which the specified predicate is true. Both the process type and the predicate can be excluded. If the process type is excluded, all process instances are checked. If the predicate is excluded, it is considered to be true.
siexists <RULE VARIABLE> [ : <SIGNAL TYPE>]
[ - <PROCESS INSTANCE>] [ | <PREDICATE>]This predicate is true if a signal (of the specified type) exists in the input port of the specified process for which the specified predicate is true. If no signal type is specified, all signals are considered. If no process instance is specified, the input ports of all process instances are considered. If no predicate is specified, it is considered to be true. The specified process can be either a rule variable that has previously been defined in an exists or all predicate, or a process instance identifier (<PROCESS TYPE>:<INSTANCE NO>).
siall <RULE VARIABLE> [ : <SIGNAL TYPE>]
[ - <PROCESS INSTANCE>] [ | <PREDICATE>]This predicate is true for all signals (of the specified type) in the input port of the specified process for which the specified predicate is true. If no signal type is specified, all signals are considered. If no process is specified, the input ports of all process instances are considered. If no predicate is specified, it is considered to be true. The specified process can be either a rule variable that has previously been defined in an exists or all predicate, or a process instance identifier (<PROCESS TYPE>:<INSTANCE NO>).
Boolean Operator Predicates
The following boolean operators are included (with the conventional interpretation):
not <PREDICATE><PREDICATE> and <PREDICATE><PREDICATE> or <PREDICATE>The operators are listed in priority order, but the priority can be changed by parenthesis.
Relational Operator Predicates
The following relational operator predicates exist:
<EXPRESSION> = <EXPRESSION><EXPRESSION> != <EXPRESSION><EXPRESSION> < <EXPRESSION><EXPRESSION> > <EXPRESSION><EXPRESSION> <= <EXPRESSION><EXPRESSION> >= <EXPRESSION>The interpretation of these predicates is conventional. The operators are only applicable to data types for which they are defined.
Expressions
The expressions that are possible to use in relational operator predicates are of the following categories:
- Process functions: Extract values from process instances
- Signal functions: Extract values from signals
- Global functions: Examine global aspects of the system state
- SDL literals: Conventional SDL constant values
Process Functions
Most of the process functions must have a process instance as a parameter. This process instance can be either a rule variable that has previously been defined in an exists or all predicate, a process instance identifier (<PROCESS TYPE>:<INSTANCE NO>) or a function that returns a process instance, e.g. sender or from.
state( <PROCESS INSTANCE> )Returns the current SDL state of the process instance.
type( <PROCESS INSTANCE> )Returns the type of the process instance.
iplen( <PROCESS INSTANCE> )Returns the length of the input port queue of the process instance.
sender( <PROCESS INSTANCE> )Returns the value of the imperative operator sender (a process instance) for the process instance.
parent( <PROCESS INSTANCE> )Returns the value of the imperative operator parent (a process instance) for the process instance.
offspring( <PROCESS INSTANCE> )Returns the value of the imperative operator offspring (a process instance) for the process instance.
self( <PROCESS INSTANCE> )Returns the value of the imperative operator self (a process instance) for the process instance.
signal( <PROCESS INSTANCE> )Returns the signal that is to be consumed if the process instance is in an SDL state. Otherwise, if the process instance is in the middle of an SDL process graph transition, it returns the signal that was consumed in the last input statement.
<PROCESS INSTANCE> -> <VARIABLE NAME>Returns the value of the specified variable. If <PROCESS INSTANCE> is a previously defined rule variable, the exists or all predicate that defined the rule variable must also include a process type specification.
<RULE VARIABLE>Returns the process instance value of <RULE VARIABLE>, which must be a rule variable bound to a process instance in an exists or all predicate.
Signal Functions
Most of the signal functions must have a signal as a parameter. This signal can be either a rule variable that has previously been defined in an siexists or siall predicate, or a function that returns a signal, e.g. signal.
sitype( <SIGNAL> )Returns the type of the signal.
to( <SIGNAL> )Returns the process instance value of the receiver of the signal.
from( <SIGNAL> )Gives the process instance value of the sender of the signal.
<RULE VARIABLE> -> <PARAMETER NUMBER>Returns the value of the specified signal parameter. The siexists or siall predicate that defined the rule variable must also include a signal type specification.
<RULE VARIABLE>Returns the signal value of <RULE VARIABLE>, which must be a rule variable bound to a signal in a siexists or siall predicate.
Global Functions
maxlen( )Gives the length of the longest input port queue in the system.
instno( [<PROCESS TYPE>] )Returns the number of instances of type <PROCESS TYPE>. If <PROCESS TYPE> is excluded the total number of process instances is returned.
depth( )Gives the depth of the current system state in the behavior tree/state space.
SDL Literals
<STATE ID><PROCESS TYPE><PROCESS INSTANCE>A process instance identifier of the format <PROCESS TYPE>:<INSTANCE NO>, e.g. Initiator:1.
<SIGNAL TYPE>nullSDL null process instance value
envReturns the value of the process instance in the environment that is the sender of all signals sent from the environment of the SDL system.
<INTEGER LITERAL>truefalse<REAL LITERAL><CHARACTER LITERAL><CHARSTRING LITERAL>SDL Restrictions
The restrictions imposed on the SDL specification by TTCN Link are basically of four different kinds:
- General SDL restrictions
- State space exploration restrictions
- Data type mapping restrictions
- TTCN name restrictions
General SDL Restrictions
TTCN Link is based on the SDL to C compiler and has thus the same restrictions as the SDL Simulator and Explorer which are also based on the SDL to C compiler. The major restrictions are:
- No context parameters
- No channel substructures
- No signal refinements
- No axioms, literal mappings, inheritance or name class literals in abstract data types
For more information about the general SDL restrictions see SDL Restrictions.
State Space Exploration Restrictions
TTCN Link is based on state space exploration of the combined state space of the SDL system and the TTCN test case. Since there is only a finite amount of memory available in computers, this means that there will be restrictions on the size of the state space that can be handled. It is not possible to give a numeric value on this restriction since it depends both on the SDL system and on the computer, but TTCN Link has been successfully used on SDL systems with more than 10 processes on a SPARCstation 10 computer. Also see Overview of the TTCN Link Algorithm.
Data Type Mapping Restrictions
Only the data types described in section Generating the Declarations are allowed on the channels to/from the system.
TTCN Name Restrictions
The mapping of concepts from SDL to TTCN generates a lot of names in TTCN. For example, the signals in SDL will become ASPs/PDUs in TTCN and SDL data types will become TTCN data types. The names of the generated entities are taken directly from the names on the corresponding SDL entity. This will lead to problems if, for example, the names are reserved words in TTCN. In this case, the names in the SDL system have to be changed.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |