Hi,

I would like to discuss a problem that has come up in various test
system development projects that I have been in touch with - the
encoding and decoding of values for external function invocations.

External functions are invoked through the TRI and hence require en- and
decoding of their parameters and return values. There is no default way
to encode/decode TTCN-3 values, which leaves each external function
implementation with the problem of defining their own codecs and also
with defining their own value representation of the decoded values in
the external function implementation level.

I have been using ASN.1 types for this purpose quite successfully -
Tau/Tester has automatic codec generation for ASN.1 types and generates
C type definitions that can be used in the external function
implementation. But this is obviously a tool dependent solution and will
only work for C/C++.

How could this problem be addressed in a tool and language independent
way? I think one way to do this would be to define a 'default encoding'
for TTCN-3 values to be used in external function invocation. When
paired with a default mapping of TTCN-3 types to C (and/or Java, etc.)
also the codec aspects in the external function implementation side
could be dealt with automatically without the external function
implementor having to deal with this explicitly.

The same codecs might also be helpful when, for example, some control
protocol is used to control SA behaviour. Such a protocol is ususally
terminated in the SA, so there is no need to use a test domain specific
encoding for these messages. Still, the SA implementor is, at the
moment, forced the develop codecs for this control protocol.

What do people think of this idea?

Another solution to this problem might be to couple TRI and the
type/value interface of the TCI, in a way that would allow passing
values through the TRI without encoding them, but make the values
accessible via the TCI API.

What do you think of this?

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi Stephan,

needless to say that I would strongly support any of your ideas .. as it allows for a simple creation of
_reusable_ TTCN-3 test system components.

If we are thinking of a external function specific solution I would think the TCI idea sounds best .. but it would
have limitations once we start seeing distributed TTCN-3 test system implementations (I think but I am not sure).

On the other hand there are other situations where you need to encode for the TRI/TCI interfaces where there may
not be a mandatory encoding. Configuration interfaces or other non standardized protocols, but most notably
procedural communication implementation (the evil twin of an external function call :)).

So I guess with a default "Nokia" encoding we could solve more problems than just external functions.
I would strongly recommend a TEXTUAL encoding as it allows users to identify easily (without any training) in
test system execution logs what information has been passed across these interfaces without a need for a fancy tool
or log handler (which needs ot be maintained by someone at the end :)).
Even partial textual encodings could help. Performance could be but should not be (I think) be an issue.

Moikka,
stephan

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]On Behalf Of ext Stephan Tobies
> Sent: 21 November, 2003 12:53
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: TTCN-3 reference codecs for external function invocation?
>
>
> Hi,
>
> I would like to discuss a problem that has come up in various test
> system development projects that I have been in touch with - the
> encoding and decoding of values for external function invocations.
>
> External functions are invoked through the TRI and hence
> require en- and
> decoding of their parameters and return values. There is no
> default way
> to encode/decode TTCN-3 values, which leaves each external function
> implementation with the problem of defining their own codecs and also
> with defining their own value representation of the decoded values in
> the external function implementation level.
>
> I have been using ASN.1 types for this purpose quite successfully -
> Tau/Tester has automatic codec generation for ASN.1 types and
> generates
> C type definitions that can be used in the external function
> implementation. But this is obviously a tool dependent
> solution and will
> only work for C/C++.
>
> How could this problem be addressed in a tool and language independent
> way? I think one way to do this would be to define a 'default
> encoding'
> for TTCN-3 values to be used in external function invocation. When
> paired with a default mapping of TTCN-3 types to C (and/or Java, etc.)
> also the codec aspects in the external function implementation side
> could be dealt with automatically without the external function
> implementor having to deal with this explicitly.
>
> The same codecs might also be helpful when, for example, some control
> protocol is used to control SA behaviour. Such a protocol is ususally
> terminated in the SA, so there is no need to use a test
> domain specific
> encoding for these messages. Still, the SA implementor is, at the
> moment, forced the develop codecs for this control protocol.
>
> What do people think of this idea?
>
> Another solution to this problem might be to couple TRI and the
> type/value interface of the TCI, in a way that would allow passing
> values through the TRI without encoding them, but make the values
> accessible via the TCI API.
>
> What do you think of this?
>
> BR
>
> Stephan
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>

Hi,

We encountered difficulties to use TTCN-3 in "white box" tests where
interfaces under tests are defined in C.

Using ASN-1 mapping may be considered heavy in this kind of environment.

The ability to have a default mapping specified between TTCN and C would be
extremely usefull.

All that goes in the direction of more genericity and simplicity to deal
with external function call is excellent to our eyes.

Mathieu Imbault
Software engineer
Skyworks Inc

Les Taissounieres HB1
1681 Route des Dolines BP 283
06905 Sophia Antipolis Cedex
France
Tel : +33493007024


|

---

+

---

>
| | Stephan Tobies |
| | <Stephan.Tobies@N|
| | OKIA.COM> |
| | |
| | 21/11/2003 11:52 |
| | Please respond to|
| | "active_ttcn3 : |
| | mts stf133 ttcn |
| | version 3 - |
| | active members |
| | only" |
| | <TTCN3@LIST.ETSI.|
| | ORG> |
| | |
|

---

+

---

>
>

---

---

|
|
|
| To: TTCN3@LIST.ETSI.ORG@SMTP@Exchange
|
| cc:
|
| Subject: TTCN-3 reference codecs for external function invocation?
|
>

---

---

|



Hi,

I would like to discuss a problem that has come up in various test
system development projects that I have been in touch with - the
encoding and decoding of values for external function invocations.

External functions are invoked through the TRI and hence require en- and
decoding of their parameters and return values. There is no default way
to encode/decode TTCN-3 values, which leaves each external function
implementation with the problem of defining their own codecs and also
with defining their own value representation of the decoded values in
the external function implementation level.

I have been using ASN.1 types for this purpose quite successfully -
Tau/Tester has automatic codec generation for ASN.1 types and generates
C type definitions that can be used in the external function
implementation. But this is obviously a tool dependent solution and will
only work for C/C++.

How could this problem be addressed in a tool and language independent
way? I think one way to do this would be to define a 'default encoding'
for TTCN-3 values to be used in external function invocation. When
paired with a default mapping of TTCN-3 types to C (and/or Java, etc.)
also the codec aspects in the external function implementation side
could be dealt with automatically without the external function
implementor having to deal with this explicitly.

The same codecs might also be helpful when, for example, some control
protocol is used to control SA behaviour. Such a protocol is ususally
terminated in the SA, so there is no need to use a test domain specific
encoding for these messages. Still, the SA implementor is, at the
moment, forced the develop codecs for this control protocol.

What do people think of this idea?

Another solution to this problem might be to couple TRI and the
type/value interface of the TCI, in a way that would allow passing
values through the TRI without encoding them, but make the values
accessible via the TCI API.

What do you think of this?

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany

Hi,

We encountered difficulties to use TTCN-3 in
"white box" tests where interfaces under tests are defined in C.

Using ASN-1 mapping may be considered heavy
in this kind of environment.

The ability to have a default mapping
specified between TTCN and C would be extremely usefull.

All that goes in the direction of more
genericity and simplicity to deal with external function call is excellent
to our eyes.

Mathieu Imbault
Software engineer
Skyworks Inc

Les Taissounieres HB1
1681 Route des Dolines BP 283
06905 Sophia Antipolis Cedex
France
Tel : +33493007024




Stephan Tobies <This email address is being protected from spambots. You need JavaScript enabled to view it.>
21/11/2003 11:52
Please respond to "active_ttcn3 : mts stf133 ttcn
version 3 - active members only" <This email address is being protected from spambots. You need JavaScript enabled to view it.>

To: TTCN3@LIST.ETSI.ORG@SMTP@Exchange
cc:
Subject: TTCN-3 reference codecs for external function
invocation?


Hi,

I would like to discuss a problem that has
come up in various test
system development projects that I have been
in touch with - the
encoding and decoding of values for external
function invocations.

External functions are invoked through the
TRI and hence require en- and
decoding of their parameters and return
values. There is no default way
to encode/decode TTCN-3 values, which leaves
each external function
implementation with the problem of defining
their own codecs and also
with defining their own value representation
of the decoded values in
the external function implementation level.

I have been using ASN.1 types for this
purpose quite successfully -
Tau/Tester has automatic codec generation
for ASN.1 types and generates
C type definitions that can be used in the
external function
implementation. But this is obviously a tool
dependent solution and will
only work for C/C++.

How could this problem be addressed in a
tool and language independent
way? I think one way to do this would be to
define a 'default encoding'
for TTCN-3 values to be used in external
function invocation. When
paired with a default mapping of TTCN-3
types to C (and/or Java, etc.)
also the codec aspects in the external
function implementation side
could be dealt with automatically without
the external function
implementor having to deal with this
explicitly.

The same codecs might also be helpful when,
for example, some control
protocol is used to control SA behaviour.
Such a protocol is ususally
terminated in the SA, so there is no need to
use a test domain specific
encoding for these messages. Still, the SA
implementor is, at the
moment, forced the develop codecs for this
control protocol.

What do people think of this idea?

Another solution to this problem might be to
couple TRI and the
type/value interface of the TCI, in a way
that would allow passing
values through the TRI without encoding
them, but make the values
accessible via the TCI API.

What do you think of this?

BR

Stephan

--
Stephan Tobies Sr. Research Engineer,
Nokia Research Center
~ Mobile Networks Lab,
Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr.
103, 44807 Bochum, Germany

Hi,

perhaps also a few words from my side.

As you might know at the time of specification of TRI there had been
some discussion on how the parameters of external functions shall be
passed to the PA. The present solution is the outcome of this discussion
from the participating parties, mainly Telelogic, Nokia and TestingTech.

The reason for this solution was (in a few words):
"All data that is passed through TRI shall be encoded according the
specification in the TTCN-3 module".

Now what type of impact does this have on the PA implementation?

Using the encoding attributes on module level would specify the so
called "default encoding". Depending on the complexity and structuring
of your test suite this would solve your problem or not.

Now to your proposals, Stephan:
- Default encoding: I am not in favor of specifying a certain default
encoding for the parameters, mainly because I would doubt that we will
find one that satisfies anybody else then the person how proposes it. As
Stephan (Schulz) wrote in a response to Stephan (Tobies) mail he would
prefer a textual encoding for readability reasons. But I think this
would introduce a unnecessary overhead for encoding and decoding. And
then there would arise the question of WHAT type of encoding, plain
textual, XML, ASN.1 value notation, or something home brewed. So I
strongly discourage this "default" approach.

- TCI integration:
Q: Why haven't TCI not been used in external functions description?
A: Because it hasn't been defined!
Q: So is it time now to integrate it?
A: I do not think so.
Q: Why ?
A: Because the standard enables tool makers to provide the most
flexible solution to their customer, because it does NOT define a
particular encoding. This does not mean of course, that the tools should
not provide one !

Let's give an example on how this problem is solved in TestingTechs
TTthree. (Let me notice that this works well for Java, and this would
also work for C and for other languages)
The runtime environment can be configured (by the user) to use any
"default" codec for the external functions he likes and he has
available. This might include the application of the encoding rules that
have been defined in the TTCN-3 module (if the user behaves like this
the TRI implementation is TRI standard compliant). But if the user
want's to use something more powerful than this, he can just use the so
called "parameter codec" of the TTthree environment. As a result of this
codec the user gets access to the parameters via the TCI value interface
WITHOUT ANY PHYSICAL ENCODING (ImplementationNote: The keywords here are
"configuration", "casting" and "TCI".)

This can be only achieved because the TRI standard does not define a
PARTICULAR encoding.

I hope I could give you some ideas how this "problem" of efficient
parameter passing could be solved by PA implementations, IFF the tool
vendors have done their homework.

For this I do not see any reason to change the specification of TRI.

Best regards,

Theo



Stephan Tobies wrote:
> Hi,
>
> I would like to discuss a problem that has come up in various test
> system development projects that I have been in touch with - the
> encoding and decoding of values for external function invocations.
>
> External functions are invoked through the TRI and hence require en- and
> decoding of their parameters and return values. There is no default way
> to encode/decode TTCN-3 values, which leaves each external function
> implementation with the problem of defining their own codecs and also
> with defining their own value representation of the decoded values in
> the external function implementation level.
>
> I have been using ASN.1 types for this purpose quite successfully -
> Tau/Tester has automatic codec generation for ASN.1 types and generates
> C type definitions that can be used in the external function
> implementation. But this is obviously a tool dependent solution and will
> only work for C/C++.
>
> How could this problem be addressed in a tool and language independent
> way? I think one way to do this would be to define a 'default encoding'
> for TTCN-3 values to be used in external function invocation. When
> paired with a default mapping of TTCN-3 types to C (and/or Java, etc.)
> also the codec aspects in the external function implementation side
> could be dealt with automatically without the external function
> implementor having to deal with this explicitly.
>
> The same codecs might also be helpful when, for example, some control
> protocol is used to control SA behaviour. Such a protocol is ususally
> terminated in the SA, so there is no need to use a test domain specific
> encoding for these messages. Still, the SA implementor is, at the
> moment, forced the develop codecs for this control protocol.
>
> What do people think of this idea?
>
> Another solution to this problem might be to couple TRI and the
> type/value interface of the TCI, in a way that would allow passing
> values through the TRI without encoding them, but make the values
> accessible via the TCI API.
>
> What do you think of this?
>
> BR
>
> Stephan
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>

Hi Mathieu,
please see my first email as an introduction.

> We encountered difficulties to use TTCN-3 in "white box" tests where
> interfaces under tests are defined in C.
>
> Using ASN-1 mapping may be considered heavy in this kind of environment.
Agreed.

>
> The ability to have a default mapping specified between TTCN and C would be
> extremely usefull.

There is already one. It is defined in the TCI standard. So it is up to
the tool that you are using whether you can make use of it or not.

>
> All that goes in the direction of more genericity and simplicity to deal
> with external function call is excellent to our eyes.
Well in TTthree you would declare your function implementation for
example for the TTCN-3 operation

external function celsius2fahrenheit(float celsius) return float;

public static FloatValue celsius2fahrenheit(FloatValue celsius)
{ ... }

The rest is done internally, using only the standardized TRI interfaces
and the configuration options as described in my previous email. Easy
enough ? ;-)

Best regards,

Theo


> Mathieu Imbault
> Software engineer
> Skyworks Inc
>
> Les Taissounieres HB1
> 1681 Route des Dolines BP 283
> 06905 Sophia Antipolis Cedex
> France
> Tel : +33493007024
>
>
> |

---

+

---

>
> | | Stephan Tobies |
> | | <Stephan.Tobies@N|
> | | OKIA.COM> |
> | | |
> | | 21/11/2003 11:52 |
> | | Please respond to|
> | | "active_ttcn3 : |
> | | mts stf133 ttcn |
> | | version 3 - |
> | | active members |
> | | only" |
> | | <TTCN3@LIST.ETSI.|
> | | ORG> |
> | | |
> |

---

+

---

>
> >

---

---

|
> |
|
> | To: TTCN3@LIST.ETSI.ORG@SMTP@Exchange
|
> | cc:
|
> | Subject: TTCN-3 reference codecs for external function invocation?
|
> >

---

---

|
>
>
>
> Hi,
>
> I would like to discuss a problem that has come up in various test
> system development projects that I have been in touch with - the
> encoding and decoding of values for external function invocations.
>
> External functions are invoked through the TRI and hence require en- and
> decoding of their parameters and return values. There is no default way
> to encode/decode TTCN-3 values, which leaves each external function
> implementation with the problem of defining their own codecs and also
> with defining their own value representation of the decoded values in
> the external function implementation level.
>
> I have been using ASN.1 types for this purpose quite successfully -
> Tau/Tester has automatic codec generation for ASN.1 types and generates
> C type definitions that can be used in the external function
> implementation. But this is obviously a tool dependent solution and will
> only work for C/C++.
>
> How could this problem be addressed in a tool and language independent
> way? I think one way to do this would be to define a 'default encoding'
> for TTCN-3 values to be used in external function invocation. When
> paired with a default mapping of TTCN-3 types to C (and/or Java, etc.)
> also the codec aspects in the external function implementation side
> could be dealt with automatically without the external function
> implementor having to deal with this explicitly.
>
> The same codecs might also be helpful when, for example, some control
> protocol is used to control SA behaviour. Such a protocol is ususally
> terminated in the SA, so there is no need to use a test domain specific
> encoding for these messages. Still, the SA implementor is, at the
> moment, forced the develop codecs for this control protocol.
>
> What do people think of this idea?
>
> Another solution to this problem might be to couple TRI and the
> type/value interface of the TCI, in a way that would allow passing
> values through the TRI without encoding them, but make the values
> accessible via the TCI API.
>
> What do you think of this?
>
> BR
>
> Stephan
>
> --
> Stephan Tobies Sr. Research Engineer, Nokia Research Center
> ~ Mobile Networks Lab, Protocol Engineering Group
> E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Work Phone: +49-234-9842262
> Fax: +49-234-9843491
> Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
>

ext Theofanis Vassiliou-Gioles wrote:

> [snip]
>
> Now to your proposals, Stephan:
> - Default encoding: I am not in favor of specifying a certain default
> encoding for the parameters, mainly because I would doubt that we will
> find one that satisfies anybody else then the person how proposes it. As
> Stephan (Schulz) wrote in a response to Stephan (Tobies) mail he would
> prefer a textual encoding for readability reasons. But I think this
> would introduce a unnecessary overhead for encoding and decoding. And
> then there would arise the question of WHAT type of encoding, plain
> textual, XML, ASN.1 value notation, or something home brewed. So I
> strongly discourage this "default" approach.


You have a valid point there. Even though, when such a default encoding
would be defined, it would mean that it is the tool vendors problem to
implement the codecs and readability/debuggability of the codecs would
not have to be much of a user's concern, so efficiency would be more
important than readability, I think. But yes, there might be
considerable effort required, which is not necessary if there would be a
better solution.

>
> - TCI integration:
> Q: Why haven't TCI not been used in external functions
> description?
> A: Because it hasn't been defined!
> Q: So is it time now to integrate it?
> A: I do not think so.
> Q: Why ?
> A: Because the standard enables tool makers to provide the most
> flexible solution to their customer, because it does NOT define a
> particular encoding. This does not mean of course, that the tools should
> not provide one !
>
> Let's give an example on how this problem is solved in
> TestingTechs
> TTthree. (Let me notice that this works well for Java, and this would
> also work for C and for other languages)
> The runtime environment can be configured (by the user) to use any
> "default" codec for the external functions he likes and he has
> available. This might include the application of the encoding rules that
> have been defined in the TTCN-3 module (if the user behaves like this
> the TRI implementation is TRI standard compliant). But if the user
> want's to use something more powerful than this, he can just use the so
> called "parameter codec" of the TTthree environment. As a result of this
> codec the user gets access to the parameters via the TCI value interface
> WITHOUT ANY PHYSICAL ENCODING (ImplementationNote: The keywords here are
> "configuration", "casting" and "TCI".)
>
> This can be only achieved because the TRI standard does not
> define a
> PARTICULAR encoding.


That was the direction that I was leaning towards, when I meant that the
TCI might be the problem to this TRI specific issue. This only came to
me when writing the mail about the encoding. But I guess you are right,
TCI 'handles' can already now be passed through the TRI and can then be
used to communicate values in both directions without the need the
change the TRI or define a default codec.

So, in other words, your approach of passing TCI handles through the TRI
does indeed solve my problem in a satisfactory manner. I will have to
check if this works for C as nicely as it does for Java, but I don't see
a reason why it should not - it should even be easier.

This looks like a very good solution to me - without the hassle of codec
standardization and implementation. Thanks for pointing this out!

BR

Stephan

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany