![]() |
![]() |
![]() |
![]() |
![]() |
Encoding
The TTCN standard says nothing about the actual encoding of values that are to be transmitted and received over the network. This aspect is being addressed in the second TTCN amendment, WDAM 2. It will allow the TTCN user to specify encodings at several levels:
- for all ASPs and/or PDUs;
- for individual ASP types and/or PDU types;
- for individual ASP parameters and/or PDU fields;
- for individual ASP constraints and/or PDU constraints;
- for individual ASP constraint parameters and/or PDU constraint fields.
Encoding ASPs
It is unusual for a standard to specify the types of the parameters that constitute an ASP. How ASPs are realized is an implementation issue, outside the scope of the standard. The types, therefore, that are given to TTCN ASPs should not be considered binding - they are there to give a consistent representation in the test suite, and are mainly for documentation purposes.
In other words, checking of ASP parameters should be consistent with the implementation of those ASPs in the test system, rather than the exact TTCN specification.
Encoding PDUs
In contrast to ASPs, PDU fields are typed in the relevant protocol standard and it is essential that these types are implemented correctly in the ETS. As far as encoding is concerned, TTCN currently refers to the standards that the PDUs are derived from. For example, if ASN.1 is used it is probable that the ASN.1 basic encoding rules (BER) rules apply, but not necessarily. Work needs to be done on this issue.
Manipulation of Encodings
In some cases of testing it may be necessary to manipulate the encoding of values, e.g. in testing of the presentation layer. This aspect, too, is addressed in WDAM 2.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |