IBM
Contents Index Previous Next



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:

  1. Adapt the SDL system to the requirements of test generation and TTCN Link.
  2. 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:

  1. Select Make from the Generate menu in the Organizer.
    The Make dialog will be opened.
  2. Select Analyze & generate code.
  3. Select Generate Makefile.
  4. Select Use Standard Kernel and TTCN Link.
  5. If necessary, change other options.
  6. Click Full Make.
    The Link executable will now be generated. It includes the information about the SDL specification that is needed for generation of the TTCN declarations. The name of the executable will be
    <sdl system name>_xxx.link
    , where xxx is depending on the compiler used.

Note:

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):

  1. You select the Link Executable.
  2. You start the generation.

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
  1. In the Organizer, select the SDL system (the top node).
  2. Select Associate from the Edit menu.
    The Associate dialog will be opened.
  3. In the dialog, select the TTCN test suite and click OK.
    The association will be indicated by a new icon placed under the test suite icon.
Selecting the Link Executable in the TTCN Suite
  1. Make sure that the test suite is opened and that the Browser is active.
  2. From the SDT Link menu point to Select Link Executable. On UNIX, it is the menu in the Browser.
    The Select Link Executable dialog will be opened.
  3. In the dialog, select the Link executable and click OK.

Note: External synonyms

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:

  1. Select Generate Declarations from the SDT Link menu. On UNIX, it is the menu in the Browser.
    This will generate the declarations and a default table.
  2. 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.
  3. 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.

SDL data type TTCN/ASN.1 data type

structure

-> SEQUENCE

array (with finite index sort)

-> SEQUENCE OF

string

-> SEQUENCE OF

bag

-> SET OF

enumerated type

-> ENUMERATED

boolean

BOOLEAN

character

Character -> IA5String (SIZE (1))

charstring

CharString -> IA5String

integer

INTEGER

real

Real -> REAL

natural

Natural -> INTEGER (0 .. MAX)

syntype

-> subtype

choice

-> CHOICE

bit

Bit -> BIT STRING (SIZE (1))

bit_string

BIT_STRING -> BIT STRING

octet

Octet -> OCTET STRING (SIZE (1))

octet_string

OCTET_STRING -> OCTET STRING

ObjectIdentifier

OBJECT_IDENTIFIER -> OBJECT IDENTIFIER

IA5String

IA5String

NumericString

NumericString

PrintableString

PrintableString

VisibleString

VisibleString

Null

NULL

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:

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:

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:

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:

Creating Test Steps

It is often useful to structure the test case into test steps. To do this by using TTCN Link:

  1. 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.
  2. Cut the lines that should form the test step from the test case.
  3. Create a test step table.
  4. Paste the lines into the new test step table and adjust the indentation level.
  5. 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:

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.

To merge the test suites:

  1. Make sure that the test suite that you want to merge the MP file into - that is, the destination document - is opened and active.
  2. In Windows, select Autolink Merge from the File menu.
    On UNIX, select Autolink Merge from the SDT Link menu in the Browser.
    A dialog will be opened.
  3. Find and select the MP file that you want to merge with the currently opened test suite.
  4. Click OK (in Windows) or Merge (on UNIX).
    The MP file you selected will be merged into the currently opened test suite.
    To complete the test suite on UNIX, you also have to generate the test suite overview. In Windows, the overview is generated automatically, for example before you print, and after that it is kept updated.

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:

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.

Figure 237 : A composed SDL/TTCN system

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.

Figure 238 : A state space fragment

Each system state represents the combined system in one moment in time. It contains information of for example:

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:

  1. Create the start system state and add it to StateSpace and TreatList.
  2. Remove one state (in step 3-4 called the current state) from TreatList.
  3. 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.
  4. For each action/resulting state:
    • If the resulting state was not already in StateSpace, add it to TreatList.
    • Add the action/resulting state to StateSpace.
  5. If TreatList is empty: Terminate algorithm, the state space of the system is now represented by the graph in StateSpace.
    If TreatList is not empty: Go to step 2.

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:

  1. You compute the state space that can be reached without any action by the test case.
  2. 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.
  3. Generate the state space that can be reached from the newly created system state(s) without any further action by the test case.
  4. 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.

Figure 239 : A structured state space

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):

  1. Select one state (in step 2-4 called the current state) from StartList.
  2. 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.
  3. 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.
  4. 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:

  1. Develop the test cases interactively by using the random walk algorithm with a small number of repetitions (1-3).
  2. 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:

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>

with a default value of 3.

PCO Type Generation Strategy

The PCO Type generation strategy is defined by the command

define-pco-type-mapping [system|channel]

and has default value system.

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]

and has default value asp.

Stable State

The stable state option is defined by the command

define-stable [on|off]

and has the default value on.

It works like this:

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:

Figure 240 : Original state space

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:

Figure 241 : The new state space with stable state assumption "off"

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:

Figure 242 : The new state space with stable state assumption "on"

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]

The default is long.

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:

Figure 243 : State space with timer mode "long"

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:

Figure 244 : State space with timer mode "short"

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']

The default value is 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 sig4
    nextstate  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 st2

If 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 st2

This 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:

Figure 245 : State space with scheduling as "all"

where

On the other hand, if the scheduling option is first, it will look like:

Figure 246 : State space with scheduling as "first"

where

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 random
define-random-rep 2

This 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:

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_All
	   RETURN

These 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.

Note:

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:

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

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>

The name of an SDL state.

<PROCESS TYPE>

The name of a process type.

<PROCESS INSTANCE>

A process instance identifier of the format <PROCESS TYPE>:<INSTANCE NO>, e.g. Initiator:1.

<SIGNAL TYPE>

The name of a signal type.

null

SDL null process instance value

env

Returns 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>
true
false
<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

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:

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
Contents Index Previous Next