Project

General

Profile

Titan TTCN3 Notes » History » Version 17

pespin, 04/05/2018 10:02 AM

1 1 laforge
h1. Titan TTCN3 Notes
2
3
Some notes about developing in Titan TTCN3, specifically regarding test cases in the Osmocom universe.
4
5 12 pespin
h1. Building / Using test cases
6 8 laforge
7
h2. Dependencies
8
9
* You'll need recent enough eclipse-titan installed: 6.2.0 is working fine, 5.5.1 is too old.
10 10 msuraev
** if you're using Debian packages, you might run into a compile error "The version of GCC does not match the expected version". If you do, it is suggested to use MAKEDEPEND_RUN define to workaround the issue. Alternatively you can edit @/usr/include/titan/cversion.h@ and comment out the related @#error@ line.
11 8 laforge
* You'll need a checkout/clone of @http://git.osmocom.org/osmo-ttcn3-hacks/@
12
13
h3. Titan Modules required
14
15
The @osmo-ttcn3-hacks@ depend on a variety of other TTCN-3 modules that you have to clone from their respective repositories.  Each test suite contains a @gen_links.sh@ script that will generate symlinks from those cloned repositories to the local directory.  If you look at @gen_links.sh@ you will see which dependencies the respective test suite has (but not their clone URLs, sorry).
16
17
For example, @sysinfo/gen_links.sh@ needs following repositories under @BASEDIR@ directory:
18
<pre>
19
git clone https://github.com/eclipse/titan.TestPorts.IPL4asp.git
20
git clone https://github.com/eclipse/titan.TestPorts.TELNETasp.git
21
git clone https://github.com/eclipse/titan.TestPorts.Common_Components.Socket-API.git
22
git clone https://github.com/eclipse/titan.Libraries.TCCUsefulFunctions.git
23
</pre>
24
25
See http://git.osmocom.org/docker-playground/tree/debian-stretch-titan/Dockerfile for a full list of dependencies
26
27
h2. Test run
28
29
For example, to run sysinfo tests do the following:
30
* adjust BASEDIR in sysinfo/gen_links.sh to match your environment
31
* adjust test configuration in sysinfo/Test.cfg if necessary
32
<pre>
33
cd sysinfo
34
./gen_links.sh
35
./regen_makefile.sh
36
make -j1 compile && make -j8
37
cd ..
38
./start-testsuite.sh sysinfo/Test sysinfo/Test.cfg
39
</pre>
40
41 9 dexter
See also https://git.osmocom.org/docker-playground/tree/ttcn3-nitb-sysinfo/
42 8 laforge
43
h3. Log files
44
45
you will receive log files in the current working directory.  You can use the @ttcn3_logmerge@ tool to merge multiple log files based on their timestamps, and you can use the @ttcn3_logformat@ tool to do some human-friendly formatting of the log files.  Harald often runs his test suite like:
46
<pre>
47 11 pespin
rm -f *.log && make -j1 compile && make -j8 && ../start-testsuite.sh MGCP_Test MGCP_Test.cfg && ttcn3_logformat *.log
48 8 laforge
</pre>
49
50
h1. Development related bits
51
52 14 pespin
h3. Learning TTCN3
53
54 17 pespin
A good set of slides about TTCN3 can be found in:
55 16 pespin
* http://download.eclipse.org/titan/TTCN3_Course_PartI_EclipseLicensed.pdf
56
* http://download.eclipse.org/titan/TTCN3_Course_PartII_EclipseLicensed.pdf
57
* http://www.ttcn-3.org/files/TTCN3_P.pdf
58 14 pespin
59 13 pespin
h2. Speedup local builds with ccache:
60
61
There's a patch in gerrit to use ccache if it is found in the build system, which provides a speedup factor of around x10.
62
63
Patch can be found in: https://gerrit.osmocom.org/#/c/7601/
64
65
Upstream should be contacted to request for inclusion of a flag to remove the "generated date" as a comment in the generated code, which prevents ccache to work fine out of the box (the provided gerrit patch workarounds this issue).
66
67 1 laforge
h2. RAW coder
68 3 msuraev
69
A lot of the messages (GSMTAP, LAPDm, L1CTL, ...) are described using the Titan extensions to the TTCN-3 type language and the associated RAW coder.
70
71 5 msuraev
Section 4.23 of the _Programmer's Technical Reference Guide for the TITAN TTCN-3 Toolset_ contains the description of this RAW coder
72
73 3 msuraev
h3. FIELDORDER
74
75
This determines the order of fields within a record or set type.
76
77
In (not only) GSM specs, typically the messages are described from first field at top to the last field at the bottom, so the logical choice here is to set "FIELDORDER(msb)" as we do in the GMS_Types.ttcn and other files.  However, there's one CAVEAT: In GSM 04.08 (and derived specs), Information Elements with 1/2 (4bit) length are ordered un-intitively.
78
79 1 laforge
Example: TS 44.018 SYSTEM INFORMATION TYPE 4:
80 4 laforge
81
 * L1 Pseudl Length (1)
82 6 msuraev
 * protocol descriptor (1/2)
83
 * skip indicator (1/2)
84
 * Message Type (1)
85
86
which then translates to:
87
88
<pre>
89
        type record RrHeader {
90
                L2PseudoLength  l2_plen,
91
                uint4_t         skip_indicator,
92
                uint4_t         rr_protocol_discriminator,
93
                RrMessageType   message_type
94
        } with { variant "FIELDORDER(msb)" };
95
</pre>
96 7 msuraev
97
Note the skip_indicator and rr_protocol_discriminator fields are swapped in their order compared to the spec!
Add picture from clipboard (Maximum size: 48.8 MB)