This proposal has been approved and the Eclipse Titan™ project has been created.
Visit the project page for the latest information and development.

Eclipse Titan

Wednesday, June 25, 2014 - 09:39 by Gyorgy Rethy
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Parent Project
Proposal State

Titan development was started in Ericsson as a research project on IP (Internet Protocol) performance testing around 2000. The function test tool used by the company at  that time was implementing the earlier version of the language, TTCN-2 (Tree and Tabular Combined Notation version 2), and was not capable of performance testing. At the same time ETSI (European Telecommunications Standards Institute) was specifying the TTCN-3 (Test and Test Control Notation version 3 - note that the name has been changed in a way leaving the abbreviation intact) test language, and it was a natural choice to use it for the new tool's prototype. In 2003 it was decided to replace the earlier TTCN-2 based test toolset by a more modern and powerful one. After a year of investigation, Titan was further developed  (TTCN-3 semantic analysis, GUI, ASN.1 support etc. added). and TTCN-2 test suites were completely replaced by TTCN-3. The Titan toolset has been evolving continuously during the last decade, and is now a proven industrial-strength product with over 4000 active licenses.


This project proposal, will use the current name of the toolset that is well-known within Ericsson.

What Titan is:

Titan is the TTCN-3-based test toolset widely used within Ericsson, providing Eclipse-based and command line user interfaces, and multi-platform support.

It is intensively used for functional testing as well as for non-functional performance testing. It can also be used for unit testing.

Titan is an integration and execution environment for test cases generated from models.

Titan supports attended and unattended (nightly) automatic test execution as well as exploratory testing.

Titan can be efficiently used for small testing tasks as well as for huge and complex test scenarios, where the tester has to communicate with the tested entity via many interfaces in a test case, at the same time. A test suite (including a test framework) of about 1M TTCN-3 LOC exists and is being used.

Titan Eclipse components contain approximately 300,000 LOC in Java, the other components contain about 1,600,000 LOC in C++ and other languages (including tests).

What Titan is not?

Titan is not a GUI testing tool.

Titan is not a test tool for low-level high capacity traffic like (Giga)Ethernet, SDH, ATM etc.


TTCN-3 (Test and Test Control Notation version 3) is the standard test specification language, developed and maintained by the European Telecommunication Standards Institute (ETSI). It is also a worldwide standard as has been endorsed by the ITU-T without technical changes. ETSI standards and ITU-T's TTCN-3 Recommendations are available for free of charge to everyone.

The portal of the TTCN-3 community is at

A rich bibliography of TTCN-3 related papers can be found at Fraunhofer Fokus's TTCN-3 site and Bernard Stepien's website.

What TTCN-3 is:

"The standardized testing language has the look and feel of a regular programming language but without the complexity that such languages often introduce, as it concentrates exclusively on testing. There are many tutorial and courses to learn TTCN-3, as well as a certification program. The standard itself provides examples that demonstrate the usage of the specific features of the language. The aim of TTCN-3 is to provide a well-defined syntax for the definition of tests independent of any application domain. The abstract nature of a TTCN-3 test system makes it possible to adapt a test system to any test environment. This separation significantly reduces the effort required for maintenance allows experts to concentrate on what to test and not on how."


See more details in the Descriptions section.

What TTCN-3 is not:

TTCN-3 is not a telecom-specific language. It is a generic-purpose test language, TTCN-3 is suited for a large variety of application domains:

  • Mobile and fixed-line communications, telecommunication networks (LTE, WiMAX, 3G, TETRA, GSM, ISDN, SS7 etc.)
  • Broadband technologies (ATM, DSL)
  • Middleware platforms (WebServices, CORBA, CCM, EJB)
  • Internet protocols, IP-based networks and applications (SIP, IMS, IPv6, SIGTRAN, XMPP, SOAP and REST based web services and many more)
  • Smart Cards, ePassport
  • Automotive (AUTOSAR, MOST, CAN)

TTCN-3 is not object oriented, it is a procedural language. One of the design principles was to specify an easy-to-learn and easy-to-use language.

TTCN-3 is not designed for developing applications, it is a testing language. Nevertheless, several protocols have been implemented with rational limitations in TTCN-3 to bridge the actually tested layer(s) and the truly available transport layers within the test tool.

Standard test suites and libraries

Several standard test suites are available. We have information that TTCN-3 is used e.g. in the automotive industry, however our knowledge is limited to test suites available from 3GPP and ETSI. Test suites for mobile and fixed-line communication, Intelligent Transport Services (ITS), ePassport, etc. are available from these organizations. These are produced for conformance, network integration/end-to-end and interoperability testing. See more information at

Except test suites, ETSI also publishes a number of TTCN-3 libraries for the IP version 6, SIP, Diameter protocols and for ITS. See available libraries at



The project aims to provide an Eclipse-based IDE for TTCN-3 based test design and execution environment. The following are within the projects scope:

  • Provide a complete test design, execution and log analysis environment for TTCN-3 within the Eclipse IDE.
  • Provide a command line test execution and result reporting interface.
  • Utilize the TTCN-3 standard.
  • Analyze TTCN-3 code quality and report metrics, code smells, code structure, all kind of information that helps the users to maintain robust and high quality code.
  • Assist the users in refactoring their TTCN-3 code.
  • Allow testing of XML interfaces and applications.
  • Allow testing of JSON interfaces and developing JSON schemas.
  • Permit the ingestion of ASN.1 and IDL specifications, describing the messaging and signal structures at the tested interfaces.
  • Utilize the capabilities of other programming languages in TTCN-3 and allow other programming languages to utilize TTCN-3 and/or Titan's advantages.
  • Provide message and signal encoding/decoding functionality within the tool, to keep test cases concentrating on the test behaviour at the higher abstraction level.
  • Provide runtime features for distributed, multi-platform and load-balanced multi-process test execution on POSIX-based operational systems as Linux, Solaris and Cygwin over Windows.
  • Provide the features to specify test execution logic, like conditional, looped, repeated execution with different sets of test data etc. 
  • Collect local test verdicts from the distributed processes (test components) of the system and calculate the overall test case verdict.
  • Provide statistics of attended or unattended test execution sessions.
  • Generate logs in different possible formats and verbosity during test execution.
  • Support continuous integration (CI), for example by providing test results for CI tools like Jenkins.
  • Provide Eclipse-based and command line log collecting and post-processing utilities.
  • Provide means for high-level test result- and detailed (low-level) log analysis.
  • Allow viewing logs in different presentation formats, like graphical. tabular/textual etc.

To help start using the toolset, a few popular, existing IP-based transports and protocols are also submitted to open source.

The following test ports (see the description section) are included into this proposal:

  • TCP, UDP, TELNET, SQL, PIPE (creating and executing command line shells from TTCN-3), SCTP, HTTP, PCAP (reading wireshark traces into TTCN-3), LANL2 (handling Ethernet frames), SIP, and Abstract Socket (it is not a test port on is own, but a library handling the TCP socket of the Linux kernel; it is used in our test ports and making it easy to develop any new test port that is using TCP).

See more information on the test port's capabilities in the Description section.

The following protocol modules are also included into this proposal:


The useful functions library contains non-domain specific utilities, like reading/writing files, get access to operational system variables, system time etc.

Any further test ports, protocol modules or generic, non-domain specific libraries, developed by contributors wil be part of this project, as they are technically closely related to the tool (due to using the test port API and message/signal encoding control of Titan).

Titan can be used for automated testing by developing test frameworks and test cases manually. But, when integrating it with modeling tools, thus providing a complete model-based-design AND model-based-testing environment, testing efficiency can be increased: test cases are generated instead of manual development, and the same environment can be used starting from the requirements engineering phase of system design up to testing of the system's functionality.

Test frameworks are domain-specific and often specific to the system under test (SUT), e.g. through managing the SUT via its management interface or accessing the SUTs internal status and data using embedded components. Sharing of libraries and frameworks developed by (Titan) users and contributors is important to the success of the test system, but due to their domain-specific nature they should not be part of this project but should create other projects, related to this one.


Titan provides an Eclipse-based IDE for TTCN-3. The user of the tool can develop test cases, test execution logic and build the executable test suite for one or more platforms.



Titan compiles and executes test cases. It has four major roles:

* The TTCN-3 design environment provides an efficient way to create the TTCN-3 test suites (called the abstract test suite, ATS). The IDE is Eclipse‑based and is called Titan Designer.

It has editors that provide the usual IDE features for TTCN-3, ASN.1 and the Titan runtime configuration file. Like creating and configuring Titan projects, syntax highlighting, name convention checking, jump to definition, on-the-fly syntax and semantic analysis, simple content assist, outline of the modules, mark occurrences etc. ASN.1 and XSD sources are typically not created by testers, but are coming from specifications. Nevertheless Titan contains a full-featured ASN.1 editor. XSD sources can be viewed, edited and validated by using any Eclipse XML editors capable of validating XSD.

The Designer also allows building the project. It has a built-in Makefile generator for GNU and GCC makes and allows setting Titan compiler and GCC compiler and linker flags. The source code is first compiled by the Titan compiler to C++ code, then external C++ compiler and linker are called to build the executable file (which is called the host controller - HC). The whole building process is invoked and controlled by the Designer and is running in a command line shell in the background .

* The Titan compiler builds an executable test suite (ETS) from the ATS, the test port code (see below) and the Titan runtime library. The ETS is not always directly executable as the TTCN-3 language and Titan allows very flexible runtime parameterization of the test cases (e.g. IP addresses, port numbers etc. in the lab); the values of runtime parameters need not be defined in development time - though default values can be specified-, but they can be provided just before the test execution session. In this way flexible execution scenarios can be created without re-building the ETS;

* Titan runtime control has several tasks:

- the Titan Main Controller (MC) read and distributes to all test components the runtime configuration parameters;

- it controls the execution of test cases in a distributed multiplatform environment;

- it keeps up and running the test system: in case of a runtime error, Titan runtime control cleans up the test system, assigns an "error" verdict to the given test case and starts execution of the next test case);

- it produces logs in different formats; Titan has a logging API and logging is done via plugins. Currently we have plugins for Titan’s own textual log format and for Jenkins (junit format). Thus, developing a new logging plugin, e.g. for LTTng doesn’t require much knowledge of Titan's code. Several logging mechanisms may be activated at the same time. Logging can be configured by verbosity and by event types. Logs can be written into files or be send to another process or via a network connection to a 3rd party tool.

Titan contains two MC implementations: a command line MC and an MC implemented in the Titan Executor Eclipse plugin.

* Command line log post-processing utilities and the Eclipse-based Titan LogViewer help analyzing the test results. These tools currently processing Titan's own log format only.

In a model-based testing (MBT) scenario, the test cases generated from the model are necessarily abstract, as the model itself does not contain low level information. Therefore the abstract test cases has to be completed by a test harness, to become executable test cases. TTCN-3 and Titan in several projects have proved to be an ideal platform for developing the test harness, for integrating the generated abstract test cases with the test harness and the test environment, and for test execution.

Though Titan is told to be "a TTCN-3 test tool", in fact it is able to use TTCN-3, ASN.1, XSD and IDL specifications describing the message and signal structures at the tested interfaces. ASN.1 is imported directly, while XSD and IDL are first converted to TTCN-3 and then the generated TTCN-3 modules are used in the projects. In case of XSD the TTCN-3 module is decorated with XML encoding instructions. Titan also supports codec control decorators in TTCN-3 files for binary and textual protocol encodings. Defining the test configurations and the dynamic behaviour of the tests are written in TTCN-3. Functions written in C/C++ can be also be called in the TTCN-3 code.

Titan consists of the following components, these are all subject of this project:




Implementation language

Titan Designer

Eclipse plugin, TTCN-3 & ASN.1 design (advanced editing, on-the-fly syntax & semantic checking) and build the executable


Titan Executor

Eclipse plugin, test execution and result reporting


Titan LogViewer

Eclipse plugin, offline log representation in tabular and graphical (UML SD-like) formats



Eclipse plugin for code quality analysis (identifies code smells, draws module dependency graph)


TTCN-3 and ASN.1 compiler

Command line parser, semantic analyzer and C++ code generator. Input files can be TTCN-3 and ASN.1.



Command line tool converting XSD documents to TTCN-3 modules, according to part-9 of the TTCN-3 standard.


Runtime library

Implementation of TTCN‑3 language elements (types, statements, operations, predefined functions etc.) and ETS side of runtime control



Command line main controller: runtime control of component distribution and central runtime control of test execution



Command line Makefile generator



Command line utility to merge the log events events based on their timestamps from the set of textual logfiles produced by the different test components independently.



Command line utility to nice-format the textual log files.



Command line utility to post filtering large log files based on the kind of logged events.



Command line utility to present not only the formatted log files but the description and TTCN–3 source code of test cases as well as the output of other network monitor programs (like tcpdump) in HTML format.



Titan is able to instrument the generated C++ code and output code coverage data in xml during runtime. This command line utility Collects and merges these output files into an LCOV input format.



Installation ~, user ~, programmer reference guides and API specification.

Microsoft Word


Test Ports

The TTCN-3 code is generic: the interfaces between the tester and the tested entity (SUT, AUT etc.) are specified at the level of the exchanged abstract data messages and signals. Setting up and maintaining the transport connections, and sending/receving "real" messages and signals are the tasks of interface adaptors. Adaptors are called test ports (TPs) and are plugins written in C++. Titan has a C++ API for adaptors that complete the ATS with the connectivity layer(s) between the test system and the SUT. 

Titan test port (adaptors) included into this project proposal provide the following capabilities:



Implementation language


Provides communicatin over TCP-type connections in IP networks. It uses the Absrtact Socket library, therefore its supports the features of the Abstract Socket described below. Connections can be static for the time of the test case (opened/starts listening at the TTCN-3 map operation and closed at unmap) or can be opened/closed dynamically from the TTCN-3 code. Multiple TCP connections are supported by one port instance.



Provides UDP-type connections in IP networks. It maps between Titan's test port API and Linux kernel's UDP socket services; supports open socket, close socket, send and receive data. One test port can handle multiple UDP connections.



Allows using remote telnet login from TTCN-3 via the TCP layer of the operating system. The test port supports client and server mode operation. In server mode operation the Telnet Test Port can handle one connection simultaneously. Supports the capabilities of Network Virtual Terminal. Telnet connection parameters (login creadentials, terminal type, prompt format with or without wildcards etc.) can be configured in Titan's runtime configuration file.



The SQL test port executes SQL statement against the SQL database. The SQL test port is able to handle different SQL engines and databases, and provides an unified interface towards them. Currently MySQL, SQLite C API-s are supported (and required from the database).



The PIPE test port is developed to execute shell commands from the TTCN-3 test suite. It provides abstract service primitives to communicate with the user. The stdin, stdout and stderr of the process are returned to the user.



ProvidesSCTP-type connections in IP networks. It maps between Titan's test port API and Linux kernel's SCTP socket services; supports open socket, close socket, send and receive data. One test port instance can handle multiple SCTP connections in either server or client mode.



Allows sending and receiving HTTP messages between the test suite and SUT via a TCP/IP connection. It uses the Abstract Socket library. Both IP version 4 and 6 are supported and it can handle multiple connections.



The PCAP test port has basically two operating modes.

In reading mode, it is able to process recorded network traffic, saved in a file in libpcap format (used e.g. also by the open source Wireshark tool), and decode various application layer protocol messages. These messages are then delivered to TTCN-3.

In capturing mode the test port can be used to capture Ethernet packets to a file, controlled from the TTCN-3 environment.

Filtering of messages can be set both at capturing and reading modes.



Allows communicating with the SUT at the low level Ethernet connectivity. The test port translates the LANL2 service primitives (ASPs) and messages (PDUs) sent from the TTCN-3 code to Ethernet II frames when sending and translates the received packets to LANL2 ASPs att receipt. The test port uses the Packet Socket on Linux and the DLPI interface on Solaris (using DLIOCRAW mode).



Handles SIP connections; The test port can handle SIP request and SIP response messages and it can use both UDP and TCP connection to send and receive messages. The built in encoder can encode SIP request and SIP response messages and it is possible to send raw and fragmented [28] messages trough the test port. The name of the header can be encoded in short or long format.

In basic mode the test port can handle only one TCP connection or one UDP socket. It is not possible to send and receive messages using both protocols at the same time, but the test port can switch between protocols and remote hosts.

In advanced mode the test port can handle several TCP connections and listen on both UDP and TCP ports at the same time. Each connection is distinguished by the protocol id, remote host name and the remote port number.

The test port used to be compatible with ETSI's SIP type definitions, therefore ETSI SIP library could be used with it. ETSI has slightly changed one of its type definition lately, therefore the test port needs to be updated to be compatible with ETSI's LibSip v2.0.


Abstract Socket

It is not a test port, but a library that can be used to build test ports that are using the TCP internet protocol connection; it uses the services provided by the UNIX socket  interface and implements basic sending, receiving and socket handling routines. It supports both IPv4 and IPv6, client and server modes and also supports SSLv2, SSLv3 and TLSv1secure connections (the used secure protocol is selected during the SSL handshake automatically).



Protocol Modules

Protocol modules implements static data structure and message encoding/decoding, defined in the specification of the given protocol. Protocols are most often specified by standard bodies for the interfaces, where equipments of different vendors may or need communicate with each other, but of course, interface specifications may also be vendor-specific. Protocol modules can support both cases and shall be in TTCN-3, ASN.1, XSD, or IDL (Corba). JSON support is being developed currently. The protocol modules made available in this project proposal are all defined by IETF and all these specifications are publically available.


TTCN-3 is a high-level, abstract language.  The code itself is platform independent (e.g. no integer value range or float precision requirements in the language, these are defined by tool implementations; memory allocation is completely solved by tools).

TTCN-3 is test environment independent. In TTCN-3 only the abstract messages/signals, exchanged between the test system and the tested entity (SUT, AUT, etc.) are defined, the transport layers and connections are provided and handled by the tools. Message/signal encoding (serialization) and decoding (deserialization) is completely done by the tool in the background. The user, if wants, can access the encoded data in TTCN-3, and the encoded data is also logged for debugging purposes. TTCN-3 also allows leaving data open in the source code and providing the actual values at execution time (i.e. typically IP- and other addresses, IDs and passwords, SUT/AUT parameters for automatic test case selection etc.). All this allows executing the test cases, unchanged, on different platforms and in different test environments.

Its main purpose is functional testing (conformance, function, integration verification, end-to-end and network integration testing) , and can also be used for performance testing. It supports testing of message-based (asynchronous), API-based (synchronous) and analog (continuous signals) interfaces and systems.

The TTCN-3 language has four major parts:

A rich data/type system

It allows describing the messages/signals of practically all possible protocols and APIs. 

Except defining data structures in TTCN-3, the language specify the ways of importing other data type/schema languages - as ASN.1, IDL, XSD and currently JSON mapping is being defined, i.e. using them in TTCN-3 test suites without the need of manual conversion. TTCN-3 can also be used as a schema language for XML and JSON (ongoing).

As an extension, Titan also allows adding encoding instructions to TTCN-3 types to automatically encode them in binary (bit-oriented) or (simple) textual forms, XML or JSON (for ASN.1 data BER/CED/DER encodings are supported).

Test configuration

TTCN-3 allows defining multi-process distributed test cases and test execution logic easily (processes are called “test components”). It is the tools' responsibility to deploy and control the test components on the available pool of machines, possibly running different OS-es. The user need not bother about the details (see also the example below). Types of the test components and their interfaces (ports) to other test components and the tested entity are defined in TTCN-3. The number of test component instances and their port connections are controlled from the test case code dynamically, using built-in language statements.

Test dynamic behaviour

TTCN-3 is a procedural programming language specialized for testing. This means that is has the usual programming language features and in addition, constructs needed for testing are built-in the language. Sending/receiving messages, checking the content of the incoming messages, alternative test behaviours depending on the response  of the tested entity(including no answer), handling timers and timeouts, logging of events, verdict assignment and collection from the different components of the test system and alike. 

Test execution control

Test case execution logic and dynamic test selection can be controlled from the TTCN-3 code itself.

TTCN-3 is a dynamically developing language. In 2003, at publication of its first implemented version, it consisted of two documents (core language and operational semantics), 316 pages in total. In 2005, in TTCN-3 edition 3, tool implementation parts and interworking with ASN.1 has been added and the language specification was published in 7 documents, on 846 pages in total. The first version of TTCN-3 edition 4, in 2009, added interworking with IDL and XSD that increased the number of published pages to 948 in 8 documents (two earlier parts had been made historical in edition 4) . From 2010 language extensions for real time and performance testing, configuration and deployment, testing of interfaces with continuous signals and some advanced language features are published in separate language extension documents. Up to now 6 language extension packages have been published and today, in June 2014, the whole language specification consists of 1422 pages in 14 documents. ETSI is securing the maintenance and development of the language by establishing a project team from ETSI members. The project is financed from ETSI budget.


The following TTCN-3 code shows a Hello Word! example, but it doesn't simply prints out the string.

The control part of the module calls the parameterized test case TC with a string parameter. TC is executed as many times in a loop as many strings are defined in the variable vl_inputs. Each test case uses two threads (called test components): one is created implicitly and automatically, when the control part of the module is started and the  testcase TC is called on this test component (during test case execution this will be the main test component - MTC). The another one is created by TC explicitly, by executing the create statement. This test component is called a parallel test component - PTC. TC then connects the ports of the two test components, commands to start execution of the function f_PTC() on the PTC and sends the string, received as parameter, to it. The MTC then waits until the PTC finishes (the done statement) and returns to the control part.

The PTC first matches the received message against the pattern specified by the TTCN-3 template t_expected. "hello world!" in all small, all capital or small with capital first letters are allowed. Whitespaces are allowed (also at the beginning and end of the string), but there shall be at least one space between "hello and "world". Exclamation mark is optional. If this match successful, the pass verdict, if unsuccessful, the fail verdict is assigned to the test case and the reason is logged (expected/not the expected message has been received plus the message itself).

module hello_world


//====================== Port Types ======================

type port MYPORT message {

  inout charstring

} with {extension "internal"}


//====================== Component Types ======================

type component MYCOMP {

  port MYPORT myport



//====================== Constants ======================

const charstring ws0 := "(\n| )#(0,)"


//====================== Templates ======================

//Strings containing the words "hello" and "world", in all small, or

//all capital letters, or small letters with first letter capital;

//exclamation mark is optional; whitespaces allowed

template charstring t_expected :=

  pattern "{ws0}(((h|H)ello {ws0}(w|W)orld)|HELLO {ws0}WORLD){ws0}!#(0,1){ws0}"


//====================== Functions ======================

function f_PTC() runs on MYCOMP {

  alt {

    [] myport.receive(t_expected){

      setverdict(pass,"expected message received: ",t_expected)


    [] myport.receive {

      setverdict(fail,"not the expected message received: ",t_expected)





//====================== Testcases ======================

testcase TC(charstring pl_toSend) runs on MYCOMP {

  var MYCOMP vl_PTC := MYCOMP.create;

  connect (self:myport, vl_PTC:myport);







// Control Part


control {

  var charstring vl_inputs [6] :=

    {"HELLO WORLD!","hello world","Hello World!","hello WORD!","hELLO wORLD!","helloworld!"}

  var integer i, vl_noStrings := sizeof(vl_inputs);

  for (i:=0; i< vl_noStrings; i:=i+1){

    execute (TC(vl_inputs[i]))


} // end of control


}  // end of module



Titan's screenshot, showing the results of the control part's execution is given below. The test case TC has been executed 6 times with different parameters. 3 times execution resulted pass 3 times fail verdict. On the left window at the middle row, the generated log file is shown. Test case results are extracted automatically from it and by clicking on a test case, its log is opened either in a graphical or in a textual/tabular form. In the middle window of the upper row the graphical view the fragment of the last execution of TC can be seen, when the string is received by the PTC and the fail verdict is assigned. By clicking on the "charstring", its content is opening in a value window that can be seen in the window below the graphical log window and at the same time the source code line producing the log event is highlighted in the TTCN-3 editor (rigth window of the middle row). The left window of the top row allows selecting the test cases/control part to be executed and shows the actual status of test components during test case runs.


Why Here?

Eclipse Foundation is a perfect place for the Titan project for the following reasons:

  • existing Eclipse IDE, code QA, test execution control and result analysis tools.
  • the Polarsys project targets robust industry-grade toolset, Titan is such a tool and it targets Polarsys
  • TTCN-3 and Titan is an ideal target language and tool for model based testing. Modeling support and tools exist in Eclipse, but no support for model based testing (MBT). Titan can complement the existing modeling tools to create a complete MBT environment from modeling to test execution and result (log) evaluation.  Such project proposal is being submitted by CEA List, with agreement and co-operation from us.
Project Scheduling

The initial contribution is already available. It will be contributed as soon as the project creation process is finished successfully.

Future Work

Titan will further be developed in Ericsson and the changed and new code be submitted to this project. Other future developments depend on further contributors to the project and their needs.

In parallel with this project proposal, a related project is being proposed by CEA List of the topic "Model based formal verification and validation". These two proposals are complementing each other with the aim to create a complete model-based-testing environment, from model specification to test generation, test execution and test result analysis. In the current stage the test cases generated from the model can be integrated with TTCN-3 based test harnesses and be executed using Titan. This will require aligning the code generator's output with the test harness interfaces and/or APIs manually. The two tools are seen by the user as two separate tools currently. We plan closer integration later, but at the point time details are not yet known as the technical discussions are still ahead of us.

We are planning to take several actions to build the community. We plan to announce open sourcing Titan and promote it at the UCAAT and HUSTEF conferences in September-October 2014. We plan to create a flyer, public website, newsletter and introduction video. Also we are planning to disseminate information about open source Titan in the traditional TTCN-3 community places as the website, the TTCN-3 article in Wikipedia, LinkedIn etc. Of course, Eplipse conferences, like EclipseCon Europe 2014, are the natural places to share information and build community. Eclipse Foundation's advice and involvement are welcome.

Project Leads
Interested Parties

- Concordia University, Montrèal: interested as user, adaptor and most probably contributors.

- CEA is interested to use Titan in a model based testing scenario. We plan to start discussion on possible roadmaps to create an integrated toolchain for model based testing using Papyrus, Titan and other open source tools.

- Thales is interested as user/adaptor.

- Eötvös Lóránd University, Budapest: they are contributors already today by contributing to the development of the Titanium plugin.

- Budapest University of Technology and Economics: they are interested as users and adaptors: Titan is being used for several years in their university course (TTCN-3 is a lab measurement topic)

Discussion with further potentially interested parties are ongoing.Further interested parties will be added during the review process.

Initial Contribution

Initial contribution exists today. It will include all tool components listed in the description section are included into the scope, and the  test ports, protocol modules and the useful functions library listed in the scope section. All these components are ready and widely used today within Ericsson.

Source Repository Type