OpenTTCN/FAQ
From OpenTTCN
Home | Developer's corner | Knowledge base | Working documents | Documentation | OpenTTCN IDE | Tutorials | Training | How do I | Frequently asked questions | Technical support |
Frequently asked questions
OpenTTCN Tester installation and activation
The "ot activate" command does not work
Q: The "ot activate" command does not work.
A: Please carefully observe the error message printed by "ot activate" command. It usually contains human-readable information about what went wrong and how to possible resolve the problem. If the error message mentions license expiration, machine configuration, an internal error or something similar, please copy the complete output of "ot activate" and send it to support@openttcn.fi.
The "ot activate" command says it cannot connect to the server
Q: The "ot activate" command cannot connect the activation server.
A: OpenTTCN online license activation and validation server has to be contacted during the activation. Some environments do not allow direct internet access, requiring the use of a proxy server instead. The activation mechanism supports HTTP and SOCKS4/5 proxies. Configuration is done as follows:
- Internet Explorer proxy settings are queried first and used if a proxy is configured there. If multiple proxies are configured, HTTP proxy is preferred over SOCKS. If you wish to disable the use of autoconfigured proxy, please run "ot activate --disable-proxy" (Windows platform only)
- If no proxy is configured, the default is to try direct connection.
- If you wish to manually configure the proxy, you may supply the information on the command line as follows:
--proxy-address ip:port (required) --proxy-type HTTP | SOCKS4 | SOCKS5 (defaults to HTTP) --proxy-login user:password (defaults to no login/password)
Let's assume your organization has a SOCKS4 proxy running on address 192.168.55.2 port 6326 you could run:
ot activate --proxy-address 192.168.55.2:6326 --proxy-type SOCKS4
If you still cannot activate, please see the next question for instructions about manual activation.
The machine running OpenTTCN tester is not connected to the internet
Q: I do not have internet connection on the machine that is running OpenTTCN tester, how can I activate the software?
A: You can use the alternate "Manual activation" method. Please follow the instructions at: http://www.openttcn.com/support/manual-activation
Periodic online license validation
My license requires periodic online license validation and I must use a proxy server
Q: My license requires periodic online license validation and I must use a proxy server for Internet access
A: You may configure the proxy settings in the configuration file. In Windows, the configuration file is located in <install path>/OpenTTCN/etc/OpenTTCN.ini. In Linux, the configuration file is either /etc/openttcn.conf or $(HOME)/.openttcn.conf. The proxy is configured using the following options. Uncomment the relevant options and set the values depending on your network configuration. If the following block of text does not exist in your configuration file, you may copy-paste it from here.
#proxy-address = ip_address:port # Supported proxy types are: HTTP, SOCKS4, SOCKS5 #proxy-type = HTTP #proxy-login = user:password # By default proxy settings are read from Internet Explorer settings (Windows only) # Uncomment the line below to disable the use of proxy. #disable-proxy = yes
OpenTTCN SDK for Java
I get java.lang.UnsatisfiedLinkError: no OTSDK error
Q: I get the following error when I try to run the adapter compiled using OpenTTCN SDK for Java:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no OTSDK in java.library.path
A: Since OpenTTCN SDK for Java uses Java Native Interface (JNI) internally, it comes with a Windows DLL as a part of the bundle. This DLL is used by the OpenTTCN SDK for Java JAR library through JNI. Therefore, you need to make this DLL visible in your DLL library search path. This can be done using java.library.path command-line property of Sun's java.exe.
If for example you have installed OpenTTCN SDK for Java to the following location:
C:\Program Files (x86)\OpenTTCN\JavaSDK
then the adapter can be launched from the command line like this:
java.exe -classpath "C:\Program Files (x86)\OpenTTCN\JavaSDK\OTSDK.jar;classes" -Djava.library.path="C:\Program Files (x86)\OpenTTCN\JavaSDK" com.example.Adapter
Note the use of java.library.path in the above script.
I get java.lang.UnsatisfiedLinkError: failed to start error
Q: I get the following error when I try to run the adapter compiled using OpenTTCN SDK for Java:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Program Files (x86)\OpenTTCN\JavaSDK\OTSDK.dll: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem
A: Please donwload and install the latest version of OpenTTCN SDK for Java. This issue is fixed in the most recent version. Please write us to sales@openttcn.fi to find out more about availability of the software.
I get java.lang.UnsupportedClassVersionError
A: Please make sure that you compile and run the adapter with JDK 1.5 or later. Please also make sure that you do not run the adapter with the JRE version that is older than the version of the Java compiler you have used to compile the adapter code.
TCI-CD interface
When a decoding hypothesis is provided and when it is not?
Accurate and reliable decoding hypothesis is provided when you are decoding parameters and return value of a signature in procedure-based communication. Decoding hypothesis is not provided by default if you are decoding a message in message-based communication or an exception. You can change this by setting the following flags in the initialization part of your adapter code:
- OT_CD_FLAG_EXCEPTIONS_WITH_HYPOTHESIS
- OT_CD_FLAG_MESSAGES_WITH_HYPOTHESIS
Please see the documentation for these two flags in include/tci/tci_ext.h for more details.
TCI-TM interface
I load a new test case using 'importer3 load' after otTMSelectSession(), but tciStartTestCase() gives error
Q: I have the following sequence of calls in my system:
- importer3 load MySession MyModule1.ttcn
- otInitAdapter(0)
- otTMSelectSession(MySession)
- tciStartTestCase(TestCaseInMyModule1)
This works fine. But then I do the following:
- importer3 load MySession MyModule2.ttcn
- tciStartTestCase(TestCaseInMyModule2)
And the test execution gives a test case error telling that test case 'TestCaseInMyModule2' is undefined. It seems that a test case list does not get updated properly. What went wrong and how do I fix this?
A: After you load a new TTCN-3 module or reload an old one, reselect the session again in your TCI-TM adapter using the following command (example in C):
otTMSelectSession(MySession);
This should enforce reallocation of the MTC and invalidation of internal system buffers it maintains, so that the test case list gets updated properly.
OpenTTCN Tester
Test log gives error message: 'create' operation failed
A: This indicates that creation of a parallel test component did not succeed. If you observe this behaviour, check the following:
- if you run under Linux, are you running out of memory on a Linux host?
- are you creating too many parallel test components so that memory runs low?
- do you have firewall settings or anti-virus software installed that suppress communication within the local host?
- is your component type definition correct? It could be that component instance may not be properly created due to incorrect variable initializer part of component variables, or due to similar reasons
If I change only one module, do I need to recompile all?
A: It depends. In many cases you will need to recompile only the module in question. In some cases you need to recompile also dependent modules.
OpenTTCN uses a conceptual separation of each top-level definition in TTCN-3 source code into declaration part and definition part. Declaration part is also historically called "header part" of a definition, therefore by analogy with C++ each module is conceptually viewed as a logical combination of C++ header file and C++ source file.
The following is a regarded as a "header part" of a top-level definition (TLD):
- for functions, testcases, altsteps: TLD identifier, list of TLD formal parameters with their types, return type, "runs on" and "system" clauses;
- for typedefs: the typedef in full;
- for global constants and module parameters: TLD identifier and its type.
The following is a regarded as a "definition part" of a top-level definition:
- for functions, testcases, altsteps: statement block;
- for global constants and module parameters: TLD value.
A general rule of thumb is such that whenever you change the "header part" of a definition, you also need to recompile modules dependent on the changed definition in question in addition to recompiling the changed module itself. If, however, you change only the "definition part", you need to recompile only the changed module itself.
Test system development
I have a requirement to build a complex test system consisting of multiple heterogeneous components
Q: I have a requirement to build a complex test system consisting of multiple heterogeneous and highly independent components. It targets a diverse set of applications under test. It involves multiple types of communication (meaning protocols and bearers), multiple transfer syntaxes (meaning codecs), and maybe even multiple languages used to develop codecs and network interface code. Do you have any hints how I can handle this complexity with your tool?
A: Yes we have. We recommend that in this case you develop each component as a self-contained software project. Each such component technically implements one single adapter process. You can develop multiple adapters that are completely independent of each other and then plug them all into the same test system using our extended adapter registration syntax. Using this syntax each adapter would claim to serve only one dedicated TSI port.
You can develop, say, adapter A that serves protocol X in C language and plug it into the test system as serving TSI port p1 by using the following adapter registration syntax in the adapter code (C language):
otRegisterAdapter("MySession", "TRI:p1");
Then you can develop, say, adapter B that serves protocol Y in Java language and plug it into the same test system as serving TSI port p2 by using the following adapter registration syntax in the adapter code (Java language):
com.openttcn.sdk.core.CAPI.instance().
otRegisterAdapter("MySession", "TRI:p2");
Similar kind of registration is also possible with our SDK for .NET.
In this way you will be able to use all these diverse adapters in the same test suite at the same time.
TTCN-3 language
Why TTCN-3 functions cannot return templates with formal parameter lists?
Q: Why the following snippet of TTCN-3 code is illegal:
template T t_inst(in template integer arg) := { val := arg }
function MyFunc() return template T
{
return t_inst;
}
function MyCaller() runs on MyMTC
{
var template T loc_var := MyFunc();
p.send(loc_var(5));
}
A: When a function returning a template actually returns, it returns effective value of the template, not template definition. Unlike template definitions, template effective values cannot have formal parameters attached to them. Enabling a function to return template definitions may have deep and undesired impact on the consistency of TTCN-3 operational semantics, and this was obviously the reason why designers of the TTCN-3 language opted not doing so.
Enabling logs for debugging purposes
OpenTTCN support may sometimes request you to enable some of these logs in order to aid in debugging a problem.
What is adapter middleware communication log and how to enable it?
Q: What is adapter middleware communication log and how to enable it?
A: The adapter middleware communication log records internal communication between components of the test system. The log is controlled by two parameters: tracelevel and tracefile. The tracelevel parameter controls the verbosity of the log, with valid values between 0 and 40 (higher is more verbose). Values higher than 25 may log the payload of the messages, possibly revealing confidential data. The tracefile parameter specifies the name of the file where the log is written.
There are two options for enabling the log: environment variables and adapter source code. You may pick whichever option is more comfortable. Modifying adapter source code may be more convenient for distributed setups while setting the environment variables may be needed if modifying the source code is undesirable or not possible.
For more information, please see documentation for otSetOrbTraceLevel() and otSetOrbTraceFile() in isl/TTCN3.h (part of the ANSI C SDK). NOTE: This feature is available in OpenTTCN Tester 2.58.0.RC1.0 and later (issue OT-813).
Enabling adapter middleware communication log by modifying source code
Perform the following calls somewhere in the adapter startup, preferably before calling otInitAdapter() or otResolveInitialReferences():
otSetOrbTraceLevel(25); // values between 0..40
otSetOrbTraceFile("C:\\work\\adaptertrace.txt"); // See isl/TTCN3.h for more options
Enabling adapter middleware communication log by using environment variables
Set the following environment variables before starting the adapter process, for example in command prompt:
set OT_SDK_ORBTRACEFILE=C:\work\adapter_trace.txt set OT_SDK_ORBTRACELEVEL=40 adapter.exe
I am using OpenTTCN version older than 2.58.0.RC1.0, can I still enabled the middleware logs?
Q: I am using OpenTTCN version older than 2.58.0.RC1.0, can I still enabled the middleware logs?
A: Yes. The logs are produced by the middleware library, and the functions provided OpenTTCN are just added for convenience. If your version does not support the OpenTTCN-specific functionality for enabling the debug output, please set the following environment variables before starting the adapter.
set ORBtraceInvocations=1 set ORBtraceInvocationReturns=1 set ORBtraceThreadId=1 set ORBtraceExceptions=1 set ORBtraceTime=1 set ORBtraceLevel=25 set ORBtraceFile=C:\work\adaptertrace.txt adapter.exe
