Hi all,
in the past days have seen on more than one occasion people playing
around with the thought about using TTCN-3 external functions to
implement time critical test behavior. I believe these people are not
fully aware of how external functions are integrated into the language
or the side effects of using them. Therefore I want to take a little
time to review what the use of external functions really means. Also
because I fear people start using this concept in the wrong way and then
come back pointing at the language stating "TTCN-3 does not allow
automatic test execution" or "how can my test case hand so
uncontrollably" or "my test does not give the same result when executed
with different TTCN-3 tools"
1. When you use external functions all bets are off
Please note that the _implementation_ of external functions is
completely out of the scope of TTCN-3! There is no guarantees on the
accurateness of this implementation and neither can a TTCN-3 compiler
check any of that implementation. When entering such a function you
loose all key TTCN-3 concepts such as matching, snapshot semantics, etc
- in essence you rely on trusting that the implementation is well
implemented and robust. Also you loose things like TTCN-3 defaults
active and guard timers runnning at the time of invocation.
Yes even when a guard timer expires there is no way how the external
function execution can be aborted.
In other words - if everything goes well - no problem. If your external
function implementation hangs or crashes you do not only hang your test
case (and prevent execution of other test cases) and loose the verdict
of the test component that called this external function - also you may
loose all the (current) verdicts of all other test components. In other
words there is basically no way to recover from such a problem.
Secondly, note that there is some interesting side effects if your
external function execution takes longer than a guard timer setting
allows (yes the external function will return and that timeout will be
waiting in the timeout queue - but only hit in the NEXT alt statement
that checks for it)
2. Tool compatibility
Please realize that a proper TRI external function _integration_ is more
cumbersome than implementing TRI communication operations! You need to
specify codecs for each function parameter as well as a external
function dispatcher.
Secondly, there is a well known deficiency in current TRI and TCI
standards in the C mappings regarding memory management. This section
had been flawed and was later obsoleted and gives tools plenty of
possibilites on how to implement handling memory management for out and
return parameters. So having the implementation work with one tool may
not mean that it works with others.
3. Well it says "function" so I should be able to use it for anything I
want
The term function is deceptive. In TTCN-3 we use functions mainly to
express behavior, i.e. with communication operations. So the quick
thought is why not do that also in external functions? Well again read
my point 1: All bets are off. My understanding is that the purpose of
external functions was to enable users to "easily" integrate algorithms
which are available in other languages, e.g., for comutation of digest
or checksum values; but definitely not to implement anything that
communicates with the SUT. Note that in TRI and TCI architectures the
external functions are in the platform adapter which shows no link with
the SUT!
4. What are you testing?
It should be obvious that external functions should _not_ be used to
implement the entire test body. Meaning verdict critical behavior should
not be in an external function implementation. Imagine such a test is
standardized .. then certification is not based on the standardized
TTCN-3 code but the external function.
5. So what can or should be used instead of external functions?
Please use communication operations - either send/receive, or
call/getcall. These operations CAN be controlled from TTCN-3 code and
can recover from unexpected behavior (which we as test engineers should
always expect!). And at the end they do the day they can be viewed as
doing exactly the same thing as an external function implementation -
meaning their TRI implementation can simply call your function with time
critical behavior. But again - remember point 4 - if this function
actually validates that a requirement is met it should be implemented in
TTCN-3.
I hope this helps or clarifies this issue,
stephan
o
o
Stephan Schulz, Ph.D.
ETSI PTCC Technical Officer
650 Rue des Lucioles
F-06921 Sophia Antipolis Cedex
Tel: +33 49294 4964
Mobile: +33 63334 8269
Fax: +33 49365 4716
o
o
