asciidoc added
diff --git a/doc/EPTF_Applib_MBT_CNL113659_FS.doc b/doc/EPTF_Applib_MBT_CNL113659_FS.doc
deleted file mode 100644
index fdd45a5..0000000
--- a/doc/EPTF_Applib_MBT_CNL113659_FS.doc
+++ /dev/null
Binary files differ
diff --git a/doc/EPTF_Applib_MBT_CNL113659_PRI.doc b/doc/EPTF_Applib_MBT_CNL113659_PRI.doc
deleted file mode 100644
index b86ff91..0000000
--- a/doc/EPTF_Applib_MBT_CNL113659_PRI.doc
+++ /dev/null
Binary files differ
diff --git a/doc/EPTF_Applib_MBT_CNL113659_UG_2.doc b/doc/EPTF_Applib_MBT_CNL113659_UG_2.doc
deleted file mode 100644
index 5e20f69..0000000
--- a/doc/EPTF_Applib_MBT_CNL113659_UG_2.doc
+++ /dev/null
Binary files differ
diff --git a/doc/FS/EPTF AppLib MBT for TitanSim, Function Specification.adoc b/doc/FS/EPTF AppLib MBT for TitanSim, Function Specification.adoc
new file mode 100644
index 0000000..61f5443
--- /dev/null
+++ b/doc/FS/EPTF AppLib MBT for TitanSim, Function Specification.adoc
@@ -0,0 +1,632 @@
+---
+Author: Jenő Balaskó
+Version: 155 17-CNL 113 659, Rev. PB2
+Date: 2018-02-15
+
+---
+= EPTF AppLib MBT for TitanSim, Function Specification
+:author: Jenő Balaskó
+:revnumber: 155 17-CNL 113 659, Rev. PB2
+:revdate: 2018-02-15
+:toc:
+
+== How to Read This Document
+
+This is the Function Specification for the MBT application library of the Ericsson Performance Test Framework (TitanSim). The modules are developed for the TTCN-3 Toolset <<_1, [1]>> with TITAN <<_2, [2]>>.
+
+== Scope
+
+The purpose of this document is to specify the content of the MBT Application Library.
+
+= General
+
+Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT).
+
+Model-based testing is the automation of black-box test design. A model based testing tool uses various test generation algorithms and strategies to generate tests from a behavioral model of the SUT.
+
+See the Model-Based Testing below:
+
+image:images/Model-Based Testing.png[alt]
+
+
+The model is usually an abstract, partial presentation of the system under test's desired behavior. The model must be concise and precise: concise so that it does not take too long to write and so that it is easy to validate with respect to the requirements but precise enough to describe the behavior that is to be tested.
+
+Test cases (including test data and oracles) can be automatically generated from the model using a model-based testing tool. The test engineer can also control the tool to focus the testing effort and manage the number of tests that are generated. The test cases derived from this model are functional tests on the same level of abstraction as the model. These test cases are collectively known as the abstract test suite. The abstract test suite cannot be directly executed against the system under test because it is on the wrong level of abstraction.
+
+The tests produced from the model are abstract tests, so they must be transformed into executable tests. Therefore an executable test suite must be derived from the abstract test suite that can communicate with the system under test. This is done by mapping the abstract test cases to concrete test cases suitable for execution. This also requires some input from the test engineer, but most model-based testing tools provide assistance with this process.
+
+Since developing a test harness is expensive one might think it would be a good idea to build a generic test harness, which can then be reused for several project. The development of such a generic test harness should be started by defining the higher-level interface of the test harness and the structure of the abstract messages. Since this interface heavily depends on the model, which in turn is very dependent on the test purpose the model was developed for, it is very hard to come up with a good interface that can be reused with as few limitations as possible.
+
+One solution can be to re-use the application libraries that were developed for the TitanSim framework. These libraries have high level abstract interfaces. They can be extended with user code and they implement a lot of protocol specific functionality. In the following section we describe the MBT application library with which it is possible to use other TitanSim application libraries as test harness for the MBT approach.
+
+= Functional Specification
+
+== Overview
+
+The architecture of a TitanSim based test harness can be seen in the figure below. The applib provides an external "MBT Applib Interface" on which it is possible to control and communicate with the test harness. This interface carries primitives that make it possible to invoke and execute test steps of the application libraries. The events reported back by the applications are also sent on this interface back to the MSC Executor.
+
+The applib can be extended so that a user defined port with user defined messages can be handled with the help of an applib. This "User mapping" code is responsible to map the incoming messages to either TitanSim functions/test steps or user defined functions. The applib events can be also caught and mapped to user defined messages, which can be sent back to the Tester component.
+
+See the TitanSim-based Test Harness below:
+
+image:images/TitanSim-based Test harness.png[alt]
+
+
+The MBT applib provides a simple FSM that can catch the reported events from the applibs and can execute all desired test steps registered by the applibs. The behavior of the FSM can be controlled via functions in the "User mapping" code, or via MBT Applib PDUs on the "MBT Applib Interface"
+
+The user glue code is where the applibs are initialized and put together. This part can also contain some user written support functions to further extend the test harness.
+
+There are two main approaches to use this test harness arrangement:
+
+1. The test harness can be controlled via the "MBT Applib Interface". In this case, the Tester must communicate via MBT Applib PDUs, that is the model must be built so that it communicates with the environment using MBT applib PDUs.
+2. The other alternative is that the model is using its own PDUs to interact with the environment. But then, the test harness must be extended with "User mapping" code that can handle these messages and can translate to MBT Applib primitives.
+
+== MBT Applib PDUs
+
+The MBT Applib is using the following PDUs.
+
+[[eptf-mbt-configrequest]]
+=== `EPTF_MBT_ConfigRequest`
+
+Direction: Tester → Test Harness
+
+Parameters:
+
+* `entityGroupName` - charstring
++
+Name of the entity group to be created
+
+* `noEntities` - integer
++
+Number of entities to be created in the group
+
+* `behaviors` - EPTF_CharstringList
++
+List of behavior that should be allocate to the group.
+
+* `fsmName` - charstring
++
+Name of the FSM to be activated for each member of the entity group.
+
+Description:
+
+The PDU declares an entity type in the test harness with the behaviors given as parameter. Then an entity group is created of this entity type. The group will contain `noEntites` number of entities. For each entity an FSM is activated. The type of FSM is specified in the `fsmName` parameter. Finally the `vf_EPTF_MBT_entityGroupCreate` call back function is invoked. This call back function must be implemented by the user and its main purpose is to init the behavior contexts and other databases as the user wish.
+
+[[eptf-mbt-configresponse]]
+=== `EPTF_MBT_ConfigResponse`
+
+Direction: Test Harness → Tester
+
+Parameters:
+
+None.
+
+Description:
+
+This PDU indicates that the recently received `EPTF_MBT_ConfigRequest` PDU was processed and executed.
+
+[[eptf-mbt-teststeprequest]]
+=== `EPTF_MBT_TestStepRequest`
+
+Direction: Test Harness → Tester
+
+Parameters:
+
+* `stepName`: charstring
++
+Name of the requested test step
+
+* `stepArgs`: EPTF_Integer_List
++
+Container of the test step arguments
+
+* `addr`: FsmAddr
++
+Address of the FSM which will execute the test step.
+
+* `Lock`: integer
++
+After the test step was executed the semaphor with this id will be unlocked by the applib.
+
+
+Description:
+
+The purpose of this PDU is to execute a test step on an FSM. The `stepName` and `stepArgs` parameters define the test step to be invoked, while the `addr` record selects an FSM of an entity in an entity group.
+
+The lock can be used to wait until the test step is executed. This can be important for example when a test step allocates an FSM context, because if the next function call would be the setting/getting of the FSM context, then this allocation must be ready.
+
+[[eptf-mbt-teststepresponse]]
+=== `EPTF_MBT_TestStepResponse`
+
+Direction: Test Harness → Tester
+
+Parameters:
+
+* `bName`: charstring
++
+Name of the behavior
+
+* `iName`: charstring
++
+Name of the event
+
+* `addr`: FsmAddr
++
+The address of the FSM who caught this event.
+
+Description:
+
+This PDU indicates that an event was received by one of the FSMs.
+
+=== `EPTF_MBT_CreateFSMRequest`
+
+Direction: Tester → Test Harness
+
+Parameters:
+
+* `entityGroupName`: charstring
++
+Name of the entity group
+
+* `eIdx`: integer
++
+Index of the entity
+
+* `fsmName`: charstring
++
+Name of the FSM to activate.
+
+Description:
+
+The purpose of this PDU is to activate a new FSM for an entity in an entity group.
+
+=== `EPTF_MBT_CreateFSMResponse`
+
+Direction: Test Harness → Tester
+
+Parameters:
+
+* `Result`: integer
++
+The result is `_-1_` in case the request wasn’t successful.
+
+* `addr`: FsmAddr
++
+The address of the FSM who caught this event.
+
+Description:
+
+This PDU indicates that the application library attempted to activate the request FSM. In case it was successful, the address of the activated FSM is in the `addr` field. Otherwise the result is set to `_-1_`.
+
+=== `EPTF_MBT_RemoveFSMRequest`
+
+Direction: Tester → Test Harness
+
+Parameters:
+
+* `addr`: FsmAddr
++
+The address of the FSM to be removed
+
+Description:
+
+The purpose of this PDU is to remove an activated FSM.
+
+=== `EPTF_MBT_CreateFSMResponse`
+
+Direction: Test Harness → Tester
+
+Parameters:
+
+* `Result`: integer
++
+The result is `_-1_` in case the request wasn’t successful.
+
+Description:
+
+This PDU indicates that the application library attempted to the FSM requested in the `RemoveFSMRequest`. In case it was unsuccessful the result is set to `_-1_`.
+
+=== `EPTF_MBT_EventDispatchRequest`
+
+Direction: Tester → Test Harness
+
+Parameters:
+
+* `bName`: charstring
++
+Name of the behavior
+
+* `iName`: integer
++
+Index of the Event
+
+* `addr`: FsmAddr
++
+Address of the FSM, where the event was reported.
+
+Description:
+This PDU request the test harness to dispatch an EPTF event to the specified FSM.
+
+
+[[eptf-mbt-userrequest]]
+=== `EPTF_MBT_UserRequest`
+
+Direction: Test Harness → Tester
+
+Parameters:
+
+* `functionName`: charstring
++
+Name of the requested test step
+* `functionArgs`: EPTF_Integer_List
++
+Container of the test step arguments
+
+Description:
+
+The purpose of this PDU is to execute a function that was registered into the CLL’s LGenBase. The `functionName` and `functionArgs` parameters define the test step to be invoked.
+
+[[eptf-mbt-commandrequest]]
+=== `EPTF_MBT_CommandRequest`
+
+Direction: Tester → Test Harness
+
+Parameters:
+
+* `quit`: QuitCommandn
++
+An empty record indicating that the test harness should start cleaning up and then exit.
+
+Description:
+
+This PDU makes the Test Harness to execute one of its management functions. Currently there is only one implements: the `quit` command, which will start the clean up process and finally the test harness exits.
+
+[[eptf-mbt-commandresponse]]
+=== `EPTF_MBT_CommandResponse`
+
+Direction: Test Harness → Tester
+
+Parameters:
+
+* `ready`: ReadyRespone
++
+An empty record indicating that the test harness finished with the initialization and is waiting for requests.
+
+* `quitAck`: QuitAckResponse
++
+An empty record indicating that the test harness has received the quit command and will start executing it.
+
+Description:
+
+The PDU contains indication on the management interface of the test harness. Two fields can be chosen: either the `ready` indication or the `quitAck` reponse.
+
+== Behavior
+
+=== MBT Behavior
+
+Constant: `c_EPTF_MBT_myBName`
+
+Name: "MBT_behavior"
+
+Description:
+
+This is the main MBT applib behavior which will create the required context space and will be used to declare events.
+
+== TestSteps
+
+=== Invoke TestStep
+
+Constant: `c_EPTF_MBT_stepName_invokeTestStep`
+
+Name: "EPTF_MBT_stepName_invokeTestStep"
+
+Function: `f_EPTF_MBT_TestStep_invokeTestStep`
+
+Arguments:
+
+Description:
+
+This test step fetches a `EPTF_MBT_TestStepRequest` PDU from the `v_EPTF_TestStepRequest` component variable looks up the test step instance based on the requested name and the executes it with the parameters described in the PDU.
+
+=== Invoke User Function
+
+Constant: ``c_EPTF_MBT_stepName_invokeUserFunction``
+
+Name: "EPTF_MBT_stepName_invokeUserFunction"
+
+Function: ``f_EPTF_MBT_TestStep_invokeUserFunction``
+
+Arguments: -
+
+Description:
+
+This test step fetches a `UserRequest` PDU from the `v_EPTF_UserRequest` component variable looks up the function pointer based on the requested name and the executes it with the parameters described in the PDU.
+
+=== Send User Response
+
+Constant: `c_EPTF_MBT_stepName_sendUserResponse`
+
+Name: "EPTF_MBT_stepName_sendUserResponse"
+
+Function: `f_EPTF_MBT_TestStep_sendUserResponse`
+
+Arguments: -
+
+Description:
+
+This test first examines whether the `vf_EPTF_MBT_createUserResponse` call back function pointer is set to a valid function. If it is, then it will call that function. The purpose of this callback function is to be able to create user mapping code that can transform any applib events to user defined PDU response.
+
+If this `vf_EPTF_MBT_createUserResponse` pointer is set to null, the test step will create an `EPTF_MBT_TestStepReponse` PDU automatically based on the caught LGenBase/Applib event.
+
+== Events
+
+=== Incoming User Request
+
+Constant: `c_EPTF_MBT_inputName_incomingUserRequest`
+
+Name: "EPTF_MBT_inputName_incomingUserRequest"
+
+Behavior: `c_EPTF_MBT_myBName`
+
+Index: 0
+
+Description:
+
+Whenever an `EPTF_MBT_UserRequest` PDU is received the MBT Applib will report this event to the FSM which is selected in the PDU’s addr parameter.
+
+=== Incoming Test Step Request
+
+Constant: `c_EPTF_MBT_inputName_incomingTestStepRequest`
+
+Name: "EPTF_MBT_inputName_incomingTestStepRequest"
+
+Behavior: `c_EPTF_MBT_myBName`
+
+Index: 1
+
+Description:
+
+Whenever an `EPTF_MBT_TestStepRequest` PDU is received the MBT Applib will report this event to the FSM which is selected in the PDU’s addr parameter.
+
+== Functions
+
+[[f-eptf-mbt-init]]
+=== `f_EPTF_MBT_init()`
+
+Parameters:
+
+* `pl_selfName`: chartstringThe name of the component instance
+* `pl_selfId`: integerThe unique id for the component type’s instance
+* `pl_entityNamePrefix`: charstringThe name of all entity groups will get this prefix
+
+Description:
+
+The function first initializes the extended component types then declares the MBT behavior type with the corresponding test steps and MBT applib events. It also sets up the MBT logging masks. Activates the MBT PDU handlers and finally it maps the MBT port.
+
+[[f-eptf-mbt-initlgenfsm]]
+=== `f_EPTF_MBT_initLGenFsm()`
+
+Parameters:
+
+* `p_userFunc`: fcb_EPTF_MBT_customUserFunction
+* `p_entityGroupCreatedFunc`: fbc_EPTG_MBT_entityGroupCreated
+
+Description:
+
+This function sets the call back function pointers in the MBT component instance and declares the MBT FSM.
+
+[[fcb-eptf-mbt-entitygroupcreated]]
+=== `fcb_EPTF_MBT_entityGroupCreated()`
+
+Parameters:
+
+* `p_req`: EPTF_MBT_ConfigRequest
+
+Description:
+
+This is a call back function signature. The function that implements this signature can be used to fill in the context databases after an entity group was created with the help of an EPTF_MBT_ConfigRequest PDU.
+
+[[fcb-eptf-mbt-customuserfunction]]
+=== `fcb_EPTF_MBT_customUserFunction()`
+
+Parameters:
+
+* `pl_ptr`: EPTF_LGenBase_TestStepArgs
+
+Description:
+
+The purpose of this callback function is to be able to create user mapping code that can transform any applib events to user defined PDU response.
+
+[[eptf-mbt-lgen-ct-the-mbt-component-type]]
+=== `EPTF_MBT_LGen_CT`: The MBT Component type
+
+Ports:
+
+* `EPTF_MBT_PCO`: EPTF_MBT_PortType
+
+Variables:
+
+* `vf_EPTF_MBT_entityGroupCreated`: fcb_EPTF_MBT_entityGroupCreated +
+ Function poninter pointing to a function which will be called after an entity group was created.
+* `vf_EPTF_MBT_createUserResponse`: fcb_EPTF_MBT_customUserFunction +
+ Function pointer pointing to a function which will be called when an event was reported and a response must be generated back to the Tester component.
+* `v_EPTF_MBT_TestStepRequest`: EPTF_MBT_TestStepRequest +
+The last received EPTF_MBT_TestStepRequest PDU.
+* `v_EPTF_MBT_ConfigRequest`: EPTF_MBT_ConfigRequest +
+The last received EPTF_MBT_ConfigRequest PDU.
+* `v_EPTF_MBT_CommandRequest`: EPTF_MBT_CommandRequest +
+The last received EPTF_MBT_CommandRequest PDU.
+* `v_EPTF_MBT_UserRequest` : EPTF_MBT_UserRequest +
+The last received EPTF_MBT_UserRequest PDU.
+
+=== `f_MBT_execute()`
+
+Parameters:
+
+* `p_name`: Charstring - name of the test step
+* `p_addr`: FsmAddr - address of the FSM
+* `p_params`: EPTF_IntegerList - parameters for the test step
+* `p_lock`: boolean - Enables/disables waiting for the test step to finish executing.
+
+Description:
+
+This function executes a test step on specifid FSM (which must run the FSM_MBT FSM. It is possible to make the function blocking until the test steps executed by setting the `p_lock` parameter to `_true_`, but it will only work in case the component extends the `EPTF_MBT_Tester_CT` and `EPTF_MBT_LGen_CT` as well!
+
+=== `f_MBT_waitFor()`
+
+Parameters:
+
+* `p_behavior`: charstring - behavior name of the expected event
+* `p_name`: charstring - name of the expected event
+* `p_addr`: FsmAddr - the event must arrive from this FSM.
+* `p_timeout`: float - Maximum waiting time for the expected event
+
+Description:
+
+This function waits for specified EPTF event to arrive. Please note, that until the waiting time runs out all the other incoming events are dropped.
+
+=== `f_MBT_dispatch()`
+
+Parameters:
+
+* `p_bName`: Charstring - behavior name of the event
+* `p_iIndex`: Integer - index of the event
+* `p_addr`: FsmAddr - the event will be sent to this FSM.
+
+Description:
+
+This function sends an EPTF event to an FSM.
+
+=== `f_MBT_activateFsm()`
+
+Parameters:
+
+* `p_entityGroupName`: charstring - entity group name of the entity
+* `p_eIdx`: integer - index of the entity
+* `p_fsmName`: charstring - the event will be sent to this FSM.
+* `p_fsmAddr`: FsmAddr - The address of the activated FSM if successful
+
+Description:
+
+This function activates an FSM on an entity.
+
+=== `f_convert_FsmAddr2TestStepArgs()`
+
+Parameters:
+
+* `p_fsmAddr`: FsmAddr - An FSM address
+* `Out`: EPTF_LGenBase_TestStepArgs - the corresponding `TestStapArgs` value
+
+Description:
+
+Utility function to convert an `FsmAddr` address to a `TestStepArgs` value.
+
+== FSMs
+
+The main FSM of the MBT applib is described here in the following figure:
+
+image:images/MBT_FSM.png[alt]
+
+The FSM is very simple: it consists of only one state. In this main state it is listening to events that are generated by the MBT applib when an MBT PDU is received and the FSM calls the corresponding handler test steps.
+
+Any other event must come from other applibs. These events must be reported back to the Tester component either by generating an `EPTF_MBT_TestStepResponse` PDU or by creating a user defined PDU. It is the `f_EPTF_MBT_sendUserResponse` test step which is responsible for this task.
+
+== TTCN Scripter for Confromiq Qtronic
+
+The MBT Applib has its own specialized TTCN Scripter for the Conformiq Qtronic MBT tool. The product has two TTCNScripter plugins:
+
+* One based on the scripter that is shipped with Conformiq Qtronic 2.1.1
+* And the other is based on Conformiq Qtronic 4.2.1
+
+Both are extended with the same additional parameters. The sources can be found in the _src/Qtronic/TTCNScripter_v*_ directories.
+
+The compiled scripter’s JAR file is in __/demo/TTCNScripter/_TTCNScripter.jar__.
+
+The MBT applib specific parameters are collected on a separate page (see figure MBT Applib settings for Qtronic TTCN Scripter below):
+
+image:images/tsapplib.jpeg[ts_applib]
+
+=== Parameter: `eptfEnable`
+
+Type: Boolean
+
+Effect:
+
+When this check box is turned on it changes the a generated code in order to be able to seamlessly compile TitanSim’s MBT applib and the generated code together:
+
+* In the generated test harness skeleton the __EPTF_MBT_PCO.send__ and __EPTF_MBT_PCO.receive__ statements are used for sending and receiving.
+* The generated main module will import the generated test harness skeleton
+* Port definition is not generated for the Applibs MBT port, it can be imported instead.
+* Type definitions are not generated for EPTF types. (All type definitions that start with "EPTF_" are skipped during code generation)
+* Port mapping/unmapping code is not generated.
+
+=== Parameter: `extendsComponent`
+
+Type: String
+
+Effect:
+
+When this string is not empty, the generated tester component will extend the component type which is given here.
+
+=== Parameter: `eptfBidirectionalPort`
+
+Type: Boolean
+
+Effect:
+
+During code generation all types in a port will have be "inout"s. That is, there will be no difference between inbound and outbound messages. The same port definition can be used to send and receive that given message types.
+
+=== Parameter: `eptfInboundPort`
+
+Type: String
+
+Effect:
+
+Here it can be specified which port is used as inbound for the test harness in the model.
+
+=== Parameter: `eptfOutboundPort`
+
+Type: String
+
+Effect:
+
+Here it can be specified which port is used as outbound for the test harness in the model.
+
+= Terminology
+
+*TitanSim Core (Load) Library(CLL):* +
+It is that part of the TitanSim software that is totally project independent. (I.e., which is not protocol-, or application-dependent). The TitanSim CLL is to be supplied and supported by the TCC organization. Any TitanSim CLL development is to be funded centrally by Ericsson.
+
+*TitanSim Appliaction Library:* +
+It is the application-specific part of the TitanSim software. It provides load generation functionalities belonging to specific protocols or products.
+
+= Abbreviations
+
+Applib:: Application Library
+
+CLL:: Core Load Library
+
+EPTF:: Ericsson Performance Test Framework
+
+FSM:: Finite State Machine
+
+MBT:: Modell Based Testing
+
+TTCN-3:: Test and Test Control Notation version 3
+
+SUT:: System Under Test
+
+TitanSim:: New synonym for the EPTF framework
+
+= References
+
+[[_1]]
+[1] ETSI ES 201 873-1 v3.2.1 (2007-02) +
+The Testing and Test Control Notation version 3. Part 1: Core Language
+
+[[_2]]
+[2] User Guide for the TITAN TTCN-3 Test Executor
+
+[[_3]]
+[3] EPTF MBT Application Library for TTCN-3 Toolset with TITAN, Reference Guide +
+Alternatively, please consult the doc/apidoc directory of the released application library.
diff --git a/doc/FS/EPTF AppLib MBT for TitanSim, Function Specification.pdf b/doc/FS/EPTF AppLib MBT for TitanSim, Function Specification.pdf
new file mode 100644
index 0000000..b6f0ec4
--- /dev/null
+++ b/doc/FS/EPTF AppLib MBT for TitanSim, Function Specification.pdf
Binary files differ
diff --git a/doc/FS/change.log b/doc/FS/change.log
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/doc/FS/change.log
diff --git a/doc/FS/images/MBT_FSM.png b/doc/FS/images/MBT_FSM.png
new file mode 100644
index 0000000..ecb47f1
--- /dev/null
+++ b/doc/FS/images/MBT_FSM.png
Binary files differ
diff --git a/doc/FS/images/Model-Based Testing.png b/doc/FS/images/Model-Based Testing.png
new file mode 100644
index 0000000..c67d0b1
--- /dev/null
+++ b/doc/FS/images/Model-Based Testing.png
Binary files differ
diff --git a/doc/FS/images/TitanSim-based Test harness.png b/doc/FS/images/TitanSim-based Test harness.png
new file mode 100644
index 0000000..b4a3324
--- /dev/null
+++ b/doc/FS/images/TitanSim-based Test harness.png
Binary files differ
diff --git a/doc/FS/images/tsapplib.jpeg b/doc/FS/images/tsapplib.jpeg
new file mode 100644
index 0000000..49f80d3
--- /dev/null
+++ b/doc/FS/images/tsapplib.jpeg
Binary files differ
diff --git a/doc/UG/EPTF AppLib MBT for TitanSim, User Guide.adoc b/doc/UG/EPTF AppLib MBT for TitanSim, User Guide.adoc
new file mode 100644
index 0000000..78e19f5
--- /dev/null
+++ b/doc/UG/EPTF AppLib MBT for TitanSim, User Guide.adoc
@@ -0,0 +1,1237 @@
+---
+Author: Jenő Balaskó
+Version: 198 17-CNL 113 659, Rev. PB2
+Date: 2018-02-15
+
+---
+= EPTF AppLib MBT for TitanSim, User Guide
+:author: Jenő Balaskó
+:revnumber: 198 17-CNL 113 659, Rev. PB2
+:revdate: 2018-02-15
+:toc:
+
+== About This Document
+
+=== How to Read This Document
+
+This is the User Guide for the MBT application library of the Ericsson Performance Test Framework (TitanSim). The application library is developed for the TTCN-3 <<_1, [1]>> Toolset with TITAN <<_2, [2]>>. This document should be read together with Function Specification <<_3, [3]>>.
+
+=== Presumed Knowledge
+
+To use this applib the knowledge of the TTCN-3 language <<_1, [1]>> is essential.
+
+= Model Based Testing of Telecommunication Software
+
+Testing takes a vital role in the software development process because creating software is an error-prone activity. Software faults occur through the following processes: a programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure. In order to avoid the consequences of errors, we must check the product in some systematic way.
+
+The definition of testing, from the IEEE Software Engineering Body of Knowledge (SWEBOK 2004) describes the top-level goals of testing: Software testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior.
+
+An important criterion that applies to telecommunications software is compatibility with systems from different vendors. This is usually achieved by the means of unambiguous specifications defined by standardization organizations. Manufacturers develop actual products according to these specifications to ensure compatibility. Conformance testing provides the means to check whether systems operate correctly according to the standard. It is crucial to create adequate test sets to minimize the time spent with testing without sacrificing reliability.
+
+The test development process itself involves significant resources: it is very time consuming and requires the manual effort of many well-trained developers. Therefore, its automation is an important challenge.
+
+== Model-Based Testing Technology
+
+Model-based testing is software testing in which test cases are derived in whole or in part from a model that describes some (usually functional) aspects of the system under test (SUT).
+
+Model-based testing is the automation of black-box test design. A model based testing tool uses various test generation algorithms and strategies to generate tests from a behavioral model of the SUT.
+
+image::images/Model-Based Testing.png[title="Model Based Testing"]
+
+The model is usually an abstract, partial presentation of the system under test's desired behavior. The model must be concise and precise: concise so that it does not take too long to write and so that it is easy to validate with respect to the requirements but precise enough to describe the behavior that is to be tested.
+
+Test cases (including test data and oracles) can be automatically generated from the model using a model-based testing tool. The test engineer can also control the tool to focus the testing effort and manage the number of tests that are generated. The test cases derived from this model are functional tests on the same level of abstraction as the model. These test cases are collectively known as the abstract test suite. The abstract test suite cannot be directly executed against the system under test because it is on the wrong level of abstraction.
+
+The tests produced from the model are abstract tests, so they must be transformed into executable tests. Therefore an executable test suite must be derived from the abstract test suite that can communicate with the system under test. This is done by mapping the abstract test cases to concrete test cases suitable for execution. This also requires some input from the test engineer, but most model-based testing tools provide assistance with this process.
+
+[[fig_2]]
+image::images/General_workflow_with_MBT.png[title="General Workflow with MBT"]
+
+
+== TitanSim as MBT Test Harness
+
+The output of the MBT tools is an abstract test suite, where each testcase is usually described with a high-level MSC which contains abstract messages to be sent and to be expected as answers. This test suite cannot be executed directly against the SUT. Therefore usually a test harness is developed that can take the abstract messages and turn them into a real life messages with the help of templates and some algorithms. Naturally, the test harness must be able to convert real-life messages to abstract high level messages as well.
+
+image::images/Test harness role.png[title="Test Harness Role"]
+
+
+In Figure 3 an executable test suite with a test harness is depicted. The Abstract Test Implementation is in fact an MSC Executor. It is connected with the test harness and can send/receive abstract messages to/from the test harness. It can also create verdicts whether the MSC execution was successful or it failed.
+
+The test harness handles this upper level API, so it can translate the abstract messages to real life messages and vice versa. To be able to do this, the test harness must implement some protocol specific functions. For example:
+
+* Transport protocol handling
+* Timeout/retransmission handling
+* Checksum calculation
+* Unique id generation
+* …
+
+In fact it must be able to handle all those protocol details, which were left out in the abstract model. Therefore development of such a framework is a difficult and laborious process.
+
+Since developing a test harness is expensive one might think it would be a good idea to build a generic test harness, which can then be reused for several project. The development of such a generic test harness should be started by defining the higher-level interface of the test harness and the structure of the abstract messages. Since this interface heavily depends on the model, which in turn is very dependent on the test purpose the model was developed for, it is very hard to come up with a good interface that can be reused with as few limitations as possible.
+
+One solution can be to re-use the application libraries that were developed for the TitanSim framework. These libraries have high level abstract interfaces. They can be extended with user code and they implement a lot of protocol specific functionality. In the following section we describe how these libraries can be used for the MBT approach.
+
+= MBT Tools
+
+== Conformiq Qtronic
+
+Conformiq Qtronic (CQ) <<_6, [6]>> is a commercial MBT tool by Conformiq. It provides both online and offline MBT. CQ works on Windows and Linux operating systems. CQ is a general-purpose MBT tool. Thus, the models and test execution techniques and algorithms are not tied to any specific domain or platform. Qtronic provides its own components for modeling and test execution, but it can be integrated with external tools.
+
+CQ has its own modeling tool but it also accepts inputting of models. Qtronic supports multi-threaded concurrent models and testing of non-deterministic systems in online mode. The modeling tool provided by CQ is the Qtronic Modeler and it uses Qtronic Modeling Language (QML). QML means UML statechart extended with java or C# code. Qtronic supports also CQλ and any UML2.0 models as input. CQλ is a variant of LISP. UML2.0 can be used for importing models from third party modeling tools. UML2.0 has to be saved in XMI format before importing. All of these can all be extended with java or with C# in the same manner as with Qtronic Modeler.
+
+image::images/Qtronic modeler.png[title="Qtronic Modeler"]
+
+Qtronic provides nine sophisticated coverage criteria, which provide good test generation guiding possibilities. In offline generation, Qtronic is able to limit search tree depth and maximum delay for response. In similar fashion to LTD, Qtronic also provides test generation based on specification requirements, which are interpreted and described in the model. CQ also provides manually created use cases for test generation guidance. Qtronic providing coverage criteria are state coverage, transition coverage, 2-transition coverage, implicit consumption, boundary value analysis, branch coverage, method coverage, statement coverage, atomic condition coverage.
+
+In Online, perspective mode the user can choose one of three alternative walking techniques: random, Markov Chain or coverage guided. The Markov Chain algorithm does not promote the same route again which means a wider scope of walking. The coverage guided walking technique focuses on covering selected coverage criteria. The coverage-guided technique is very useful when the testing time is short. In online mode, the user can also define the maximum latency time. Test execution can optionally be paused automatically, stopped when all coverage criteria are fulfilled, or stopped after a single test run.
+
+In offline mode the user is able to choose look ahead depth and maximum delay time. Look ahead depth controls the amount of CPU time used for planning the test scripts. Maximum delay signifies response waiting time after the sending of input. The offline mode also makes it possible to minimize the size of the test sets, or to generate only finalized test sets.
+
+image::images/Qtronic perspective in Eclipse.png[title="Qtronic perspective in Eclipse"]
+
+Adaptation is done by plug-ins: scripter plug-in for offline while MBT and both adapter and logging plug-ins for online testing. The plug-ins can be performed in C++ or Java. The Qtronic package already has some plug-ins, for example TTCN-3 or HTML scripter. It is easy to make a new plug-in for a specific format.
+
+Conformiq Qtronic is a true MBT tool with a very general approach. Open plugins makes the tool highly flexible and easily adaptable to different domains.
+
+== Spec Explorer
+
+Spec Explorer <<_5, [5]>> is a MBT tool that is allowed for use in any non-commercial purpose. It is made by Microsoft and accepts only Windows as its operating system. It can test in both offline and online approaches. Spec Explorer is strongly tied to Visual Studio. It uses Visual Studio’s (VS) formats, and does compilation in VS.
+
+Spec Explorer uses the textual notations: Abstract State Machine Language (AsmL) and Spec# for modeling. ASML is an executable specification language based on the theory of Abstract State Machines. Spec# is an extended version of C#, with extension to support non-null types and checked exceptions. Modeling can be done with text editors or with an integrated graphical editor. Spec Explorer generates visual finite state machine (FSM) from textual notation for illustration.
+
+When there is a requirement to run the test suite automatically against the implementation of the system it was necessary to write an adapter for mapping Spec Explorer and SUT together. The adapter may be written in C# or Visual Basic.
+
+Spec Explorer offers few coverage criteria. The offline approach gives random walk, transition coverage or shortest path algorithm. Online testing works only with randomly walking. There are also some searching algorithms for sharpening test set quality that affect both testing approaches.
+
+Both offline and online testing are executable in Spec Explorer. It is also possible to export offline test suite in xml format or export executable test code in Visual Basic or C# language. Online testing can be started directly from the Spec Explorer and the tool will continue to run test cases against the model until SUT fails or the user stops the execution process.
+
+image::images/se_workflow.png[title="Workflow of Spec Explorer"]
+
+Spec Explorer can receive the following inputs:
+
+* A set of .NET model assemblies. The .NET assemblies are created from a model program in C# or another .NET language. Model source is compiled with a standard compiler. It is usually annotated with custom attributes for marking modeling constructs. Other model notations, such as diagrams, can be incorporated by first translating them into C# or to the Cord scripting language.
+* A set of .NET harness, or adapter, assemblies. These can potentially include the implementation under test. If the implementation under test is included, its presence enables the tool to validate consistency of bindings from model to implementation. There is no difference between model assemblies and implementation/harness/adapter assemblies; that is, they all constitute a single set of assemblies referenced by Spec Explorer.
+* A set of coordination (Cord) scripts, which describe action sets, mapping to metadata in provided assemblies, configuration options, and behaviors in the form of action machine definitions.
+* An exploration goal provided through the user interface (UI) or the command line, which identifies the machine to explore and the exploration method to use for it.
+
+Based on these inputs, the core algorithmic functionality of the tool is the following:
+
+* Validating the consistency of the inputs. This means checking whether references in the scripts to elements in the assemblies are resolvable, as well as checking the syntax and context conditions of the script language itself.
+* Running exploration, as defined by the exploration goal. This means systematically running the goal machine to determine the reachable state space and state transitions.
+
+The goal machine can be specified by the scripts, by a reference to a model program from the assemblies, or by composition or transformation of other machines. Processes traditionally available in model-based testing tools such as traversals are represented as particular transformations on machines, which provides a uniform paradigm for state exploration and traversal.
+
+The outputs from running an exploration are presented and processed in the following way:
+
+* The state graph that results from exploration. The user can click states and steps in the graph and inspect their content and properties. The display can be configured in various ways in a Cord script.
+* The graph is also encoded in a data structure called the transition system. This is a programmatic representation with a direct correspondence to an XML format that can be output. Moreover, the transition system can be translated into C# code that runs offline tests.
+
+Because exploration and traversal are unified, the result of exploration—whether displayed as a graph, XML transition system, or C# test suite—can represent various logical artifacts: the explored state space, a test suite, a model-checking counterexample, or the log of a test run.
+
+image::images/Spec Explorer in Visual Studio.png[title="Spec Explorer in Visual Studio - Exploration"]
+
+Spec Explorer is most useful when you are familiar with Visual Studio. Unfortunately, it is just for research purposes. Based on this, however, a very sophisticated tool from Microsoft is being developed.
+
+= The MBT Application Library
+
+== Overview
+
+The architecture of a TitanSim based test harness can be seen in the figure below. The applib provides an external "MBT Applib Interface" on which it is possible to control and communicate with the test harness. This interface carries primitives that make it possible to invoke and execute test steps of the application libraries. The events reported back by the applications are also sent on this interface back to the MSC Executor.
+
+The applib can be extended so that a user defined port with user defined messages can be handled with the help of an applib. This "User mapping" code is responsible to map the incoming messages to either TitanSim functions/test steps or user defined functions. The applib events can be also caught and mapped to user defined messages, which can be sent back to the Tester component.
+
+image::images/TitanSim-Based_Test_Harness.png[title="TitanSim-Based Test Harness"]
+
+The MBT applib provides a simple FSM that can catch the reported events from the applibs and can execute all desired test steps registered by the applibs. The behavior of the FSM can be controlled via functions in the "User mapping" code, or via MBT Applib PDUs on the "MBT Applib Interface".
+
+The user glue code is where the applibs are initialized and put together. This part can also contain some user written support functions to further extend the test harness.
+
+There are two main approaches to use this test harness arrangement:
+
+1. The test harness can be controlled via the "MBT Applib Interface". In this case, the Tester must communicate via MBT Applib PDUs, that is the model must be built so that it communicates with the environment using MBT applib PDUs.
+2. The other alternative is that the model is using its own PDUs to interact with the environment. But then, the test harness must be extended with "User mapping" code that can handle these messages and can translate to MBT Applib primitives.
+
+== Simple MBT Applib Demo
+
+A simple TitanSim project demonstrating the usage of the MBT Applib can be found in the demo directory of the product. It consists of the following files:
+
+* __MBT_demo.prj__ +
+ mctr_gui project file containing all information to be able to build the project.
+* __MBT_demo.ttcn__ +
+ TTCN module that contains all the TTCN sources that were written for this demo.
+* __MBT_demo.cfg__ +
+ Sample config file in order to be able to execute the demo
+* __Makefile_patch.sh__ +
+ _Makefile_ patcher shell script that is used by mctr_gui to build the demo project.
+
+=== Test Arrangement
+
+image::images/Component_Arrangement_in_the_simple_demo.png[title="Component Arrangement in the simple demo"]
+
+The component arrangement of the demo can be seen in the figure above. In the testcase started on MTC the following steps are executed:
+
+1. Creating the Tester Component
+2. Creating and connecting with the Test Harness
+3. Starting The behaviors on both components
+4. Waiting for shutdown
+
+Example:
+
+[source]
+----
+testcase tc_MBT_HTTP_Demo() runs on MBT_Demo_Main_CT
+{
+ f_EPTF_Base_init_CT("mtc");
+
+ var MBT_Demo_LGen_CT vc_MBT_CT := MBT_Demo_LGen_CT.create;
+ var MBT_Demo_Tester_CT vc_Tester_CT := MBT_Demo_Tester_CT.create;
+
+ connect(vc_MBT_CT:EPTF_MBT_PCO, vc_Tester_CT:EPTF_MBT_PCO);
+
+ vc_MBT_CT.start(f_MBT_Demo_LGen_HTTP_behavior());
+ vc_Tester_CT.start(f_MBT_Demo_Tester_HTTP_behavior());
+
+ //all component.done;
+ f_EPTF_Base_wait4Shutdown();
+}
+----
+
+=== Tester Behavior
+
+The Tester component is an instance of the `MBT_Demo_Tester_CT` component type which extends the `EPTF_MBT_Tester_CT` component type defined by the MBT Applib. This component has an `EPTF_MBT_PCO` port, so it can communicate with the Test Harness using the MBT Applib’s API.
+
+The main function which is executed on this component has the following structure:
+
+1. Initialization
+2. `EPTF_MBT_ConfigRequest` PDU is sent to the Test Harness to setup the entity group. The `ConfigResponse` must arrive to indicate, that the configuration was successful.
+3. `EPTF_MBT_TestStepRequests` are sent to to execute protocol specific behavior in the test harness, and the incoming responses are reported back to the Tester component via `EPTF_MBT_TestStepResponse` PDUs
+4. Finally, a quit command is sent to the Test Harness
+5. The Tester waits until the clean up process is finished using the `f_EPTF_Base_wait4Shutdown()` function.
+
+Example:
+
+[source]
+----
+function f_MBT_Demo_Tester_HTTP_behavior() runs on MBT_Demo_Tester_CT
+{
+ f_EPTF_Base_init_CT("MBT_Demo_Tester");
+
+ EPTF_MBT_TESTER_PCO.send(EPTF_MBT_ConfigRequest:
+ {
+ entityGroupName := "MBT_EntityType",
+ noEntities := 1,
+ behaviors := {"MBT_behavior", "HTTP Behavior"},
+ fsmName := "FSM_MBT"
+ }
+ );
+
+ // TODO: activate default altstep, with timeout handling
+
+ EPTF_MBT_TESTER_PCO.receive(EPTF_MBT_ConfigResponse:?);
+
+EPTF_MBT_TESTER_PCO.send(EPTF_MBT_TestStepRequest:
+ {"EPTF HTTP: Sends HTTP Request", {}, omit, omit});
+
+EPTF_MBT_TESTER_PCO.receive(EPTF_MBT_TestStepResponse:
+ { bName := "HTTP Behavior",
+ iName := "HTTP CHAR Response Message Received"});", addr :=*});
+
+ EPTF_MBT_TESTER_PCO.send(EPTF_MBT_CommandRequest:{ quit := {}});
+
+ f_EPTF_Base_wait4Shutdown();
+}
+----
+
+=== Test Harness Behavior
+
+The Test Harness is an instance of `MBT_Demo_LGen_CT` which extends `EPTF_MBT_LGen_CT` component type defined by the MBT applib and all required component types in order to be able to use the desired application libraries.
+
+The main function on the Test Harness has the following responsibilities:
+
+1. Init the component
+2. Init the used application libraries
+3. Init the MBT FSM
+4. Specify the function that will fill in the simulated entities user databases
+5. The Test Harness waits until the clean up process is finished using the `f_EPTF_Base_wait4Shutdown()` function.
+
+Example:
+
+[source]
+----
+function f_MBT_Demo_LGen_HTTP_behavior() runs on MBT_Demo_LGen_CT
+{
+ f_EPTF_MBT_init("MBT_Demo_LGen",0, "MBT_");
+
+ f_EPTF_HTTP_init(
+ pl_selfName:="HTTP_LoadGen",
+ pl_selfId:=0,
+ pl_entityNamePrefix:="HTTP_AppLib_",
+ pl_numEntities:=0)
+
+ f_EPTF_HTTP_LocalTransport_init_CT(
+ pl_selfName:="EPTF_HTTP_LocalTransport",
+ pl_receiveFunction:=refers(f_EPTF_HTTP_messageReceived),
+ pl_eventReceiveFunction:=refers(f_EPTF_HTTP_eventReceived));
+
+ // Further HTTP applib initialization comes here (e.g. local transport)
+
+ f_EPTF_MBT_initLGenFsm
+ (
+ null,
+ refers(f_EPTF_MBT_HTTP_Demo_fillInDB)
+ );
+
+ f_EPTF_Base_wait4Shutdown();
+}
+----
+
+=== Testcase Execution Example
+
+An example scenario of the execution can be seen in figure below:
+
+image::images/Simple_Demo_Signaling.png[title="Simple Demo Signaling"]
+
+1. Tester component is created, initialized and the corresponding behavior function is started.
+2. Test Harness component is created, initialized and the corresponding behavior function is started.
+3. `EPTF_MBT_ConfigRequest` is sent to create the entity group and activate the MBT_FSM.
+4. `EPTF_MBT_ConfigResponse` is sent to report the configuration was successful.
+5. `EPTF_MBT_TestStepRequest` is sent to execute the HTTP send request in the Test Harness
+6. HTTP Request is sent out to the SUT.
+7. The SUT responds with an answer.
+8. The HTTP applib reports an event to the FSM, which in turn generates an `EPTF_MBT_TestStepResponse` to the Tester. This PDU describes the event it received.
+9. Finally an `EPTF_MBT_CommandRequest` is sent to exit from the current configuration and clean up the test system.
+
+[[MBT_Applib_Demo_with_Qtronic_Using_User-Defined_Messages]]
+== MBT Applib Demo with Qtronic Using User-Defined Messages
+
+The Conformiq Qtronic MBT tool is shipped with a demo that models a SIP phone. The goal of the MBT Applib demo for Qtronic is to implement a test harness that is able to generate real-life SIP messages for the abstract test generated from the SIP demo model.
+
+[[SUT_SIP_Phone]]
+=== SUT: SIP Phone
+
+To create the demo, the System under test was also implemented in the TitanSim Framework, using the MBT Applib. The SUT has two interfaces, the upper one can receive commands:
+
+* Invite +
+To start a session
+* Cancel +
+To cancel an initiated session
+* Bye +
+To finish an established session
+
+The lower interface:
+
+* Can receive SIP messages (e.g. 200 OK, 486 Busy …)
+* And send SIP messages (e.g. INVITE, CANCEL)
+
+The state machine of the SIP phone can be seen in figure below. "i:" mark means that the transition will be traversed when that message event is received in the given state, while “o: “ means, that during the state change those messages are sent which are enumerated there.
+
+image::images/SUT_SIP_Phone.png[title="SUT: SIP Phone"]
+
+The source code of the SUT implementation can be found in these module:
+
+* __demo/sut/_MBT_SUT_SIP_Phone.ttcn__
+
+=== Demo Files
+
+The demo consists of the following files:
+
+* Qtronic Model of the SUT
+** __demo/mapped/model/_SIPClient.java__
+** __demo/mapped/model/_SIPClient.xmi__
+* User written files
+** __Demo/MBT_Qtronic_Demo.prj__ +
+ Project file that builds the whole project.
+** __Demo/MBT_Qtronic_Demo.cfg__ +
+ Sample config file to be able to execute the testcases.
+** __Demo/MBT_Qtronic_Demo.ttcn__ +
+ User written code for initialization, configuration and mapping.
+* Generated files by Qtronic
+** __Demo/MBT_Qtronic_Testcases.ttcn__ +
+ This contains the generated testcases.
+** __Demo/MBT_Qtronic_TestHarness.ttcn__ +
+ The send/receive functions can be found here.
+** __Demo/MBT_Qtronic_Types.ttcn__ +
+ The generated type definitions for the abstract test data.
+* TTCN-3 Scripter
+** __Demo/TTCNScripter/TTCNScripter_V211.jar__
+
+=== Test Arrangement Overview
+
+The demo’s test arrangement can be found in the figure below. There are three main actors: the Tester, which executes the abstract test; the Test Harness, which provides the mapping between the abstract test data and a real-life test PDU; and finally the System Under Test.
+
+image::images/Qtronic_Demo_Component_Structure.png[title="Qtronic Demo Component Structure"]
+
+The Tester controls the SUT and the Test Harness. It is built mostly from generated code, the only exceptions are the function that are responsible for creating and connecting the components.
+
+The Test Harness contains the MBT and the SIP application libraries. On top of these is the user mapping code, which must implement the mapping between the MBT Applib/SIP Applib API and the abstract test data.
+
+=== Tester Code Examples
+
+The Tester component is an instance of the `MBT_Qtronic_Demo_Tester_CT` component type which extends the `EPTF_MBT_Tester_CT` component type defined by the MBT Applib. This component has an `EPTF_MBT_PCO` port, so it can communicate with the Test Harness using the MBT Applib’s API.
+
+The `f_MBT_Qtronic_Demo_beginTestcase()` function on the Test Harness is invoked each time a test case is started. Its role is to create, connect and init the components:
+
+1. Initialize
+2. Create the Test Harness
+3. Connect the Test Harness with the Tester
+4. Send `EPTF_MBT_ConfigRequest` PDU to the Test Harness to setup the entity group. The `ConfigResponse` must arrive to indicate, that the configuration was successful.
+
+Example:
+
+[source]
+----
+function f_MBT_Qtronic_Demo_beginTestCase() runs on Qtronic_CT
+{
+ log(%definitionId, " started");
+
+ f_EPTF_Base_init_CT("mtc");
+
+ log(%definitionId, " Creating LGen");
+ var MBT_Qtronic_Demo_LGen_CT vc_lgen := MBT_Qtronic_Demo_LGen_CT.create;
+ connect(self:netIn, vc_lgen:netOut);
+ connect(self:netOut, vc_lgen:netIn);
+ connect(self:EPTF_MBT_TESTER_PCO,vc_lgen:EPTF_MBT_PCO);
+ vc_lgen.start(f_MBT_Qtronic_Demo_LGen_behavior());
+
+ EPTF_MBT_TESTER_PCO.receive(EPTF_MBT_CommandResponse:?) from vc_lgen;
+
+ EPTF_MBT_TESTER_PCO.send(EPTF_MBT_ConfigRequest:
+ {
+ entityGroupName := "MBT_EntityType",
+ noEntities := 1,
+ behaviors := {"MBT_behavior", "Behavior_SIP"},
+ fsmName := "FSM_MBT"
+ }
+ ) to vc_lgen;
+ EPTF_MBT_TESTER_PCO.receive(EPTF_MBT_ConfigResponse:?) from vc_lgen;
+
+ log(%definitionId, " LGen ready");
+
+ log(%definitionId, " finished");
+}
+----
+
+The `f_MBT_Qtronic_Demo_endTestcase()` function on the Test Harness is invoked each time a test case is started. Its role is to create, connect and init the components:
+
+1. Stop all the components
+2. Wait until all components are finished with the clean up.
+
+Example:
+
+[source]
+----
+function f_MBT_Qtronic_Demo_endTestCase() runs on Qtronic_CT
+{
+ log("### MAIN: END TESTCASE started");
+
+ f_EPTF_Base_stopAll(none, true);
+
+ log("### MAIN: END TESTCASE finished");
+}
+----
+
+=== Test Harness Code Examples
+
+==== Test Harness Behavior Function
+
+The Test Harness is an instance of `MBT_Qtronic_Demo_LGen_CT` which extends `EPTF_MBT_LGen_CT` component type defined by the MBT applib and all required component types in order to be able to use the desired application libraries.
+
+The main function on the Test Harness has the following responsibilities:
+
+1. Init the component
+2. Init the used application libraries
+3. Init the MBT FSM
+4. Specify the function that will fill in the simulated entities user databases
+5. Activate the altstep that will handle the incoming abstract test data PDUs.
+6. The Test Harness waits until the clean up process is finished using the `f_EPTF_Base_wait4Shutdown()` function.
+
+Example:
+
+[source]
+----
+function f_MBT_Qtronic_Demo_LGen_behavior() runs on MBT_Qtronic_Demo_LGen_CT
+{
+ activate(as_MBT_Qtronic_Demo_LGen_userMessageHandler());
+
+ f_EPTF_MBT_init("MBT_Demo_LGen",0, "MBT_")
+
+ f_SIP_applibInit("MBT_Demo_LGen");
+
+ f_EPTF_SIP_LocalTransport_init(tsp_MBT_SIP_Transport);
+
+ vf_EPTF_SIP_LocalTransport_receive :=
+ refers(f_EPTF_SIP_Message_MsgHandler);
+ vf_EPTF_SIP_LGen_msgSender :=
+ refers(f_EPTF_SIP_LocalTransport_sendSIPMessage);
+ v_removeUAS :=
+ refers(fcb_EPTF_SIP_LocalTransport_removeUAS);
+
+ f_EPTF_MBT_initLGenFsm
+ (
+ refers(f_MBT_Qtronic_Demo_LGen_createUserMessage),
+ refers(f_MBT_Qtronic_Demo_LGen_fillInDB)
+ );
+
+ EPTF_MBT_PCO.send(EPTF_MBT_CommandResponse:{ ready := {}}) to mtc;
+
+ f_EPTF_Base_wait4Shutdown();
+}
+----
+
+==== User Mapping
+
+The mapping of the abstract test data used in the model is realized in two functions:
+
+* An altstep must be written and activated which is able to process the incoming abstract test data and map it to Applib functions.
+* A function must be written, which is able to produce abstract test data based on TitanSim Applib events, or real life PDUs.
+
+Example Altstep:
+
+[source]
+----
+altstep as_MBT_Qtronic_Demo_LGen_userMessageHandler()
+runs on MBT_Qtronic_Demo_LGen_CT
+{
+ var SIPResp vl_SIPResp;
+ var SIPReq vl_SIPReq;
+
+ var EPTF_LGenBase_TestStepArgs vl_stepArgs :=
+{ eIdx := 0, refContext :=
+ { fCtxIdx := 0, fRefArgs := { } }, stepArgs := { }
+};
+
+ [] netOut.receive(SIPResp:?) -> value vl_SIPResp
+ {
+ f_EPTF_SchedulerComp_refreshSnapshotTime();
+ log(%definitionId & "(): incoming ", vl_SIPResp);
+
+ if (vl_SIPResp.status == 180)
+ {
+ vl_stepArgs.refContext.fRefArgs := {c_status_180Ringing_idx};
+ f_SIP_step_createResponse(vl_stepArgs);
+ }
+ else if (vl_SIPResp.status == 200)
+ {
+ if (vl_SIPResp.cseq == "INVITE")
+ {
+ vl_stepArgs.refContext.fRefArgs :=
+ {c_status_200OK_idx, c_SIP_Method_INVITE};
+ f_SIP_step_createResponse(vl_stepArgs);
+ }
+ else if (vl_SIPResp.cseq == "CANCEL")
+ {
+ vl_stepArgs.refContext.fRefArgs :=
+ {c_status_200OK_idx, c_SIP_Method_CANCEL};
+ f_SIP_step_createResponse(vl_stepArgs);
+ }
+ }
+ //. . .
+ else
+ {
+ log(%definitionId & "(): unhandled SIPResp");
+ }
+
+ repeat;
+ }
+ [] netOut.receive(SIPReq:?) -> value vl_SIPReq
+ {
+ f_EPTF_SchedulerComp_refreshSnapshotTime();
+ log(%definitionId & "(): incoming ", vl_SIPReq);
+
+ if (vl_SIPReq.op == "BYE")
+ {
+ f_SIP_step_createBYE(vl_stepArgs);
+ }
+ else
+ {
+ log(%definitionId & "(): unhandled SIPReq");
+ }
+ repeat;
+ }
+}
+----
+
+Example Abstract PDU Producer:
+
+[source]
+----
+function f_MBT_Qtronic_Demo_LGen_createUserMessage
+ (in EPTF_LGenBase_TestStepArgs pl_ptr)
+runs on MBT_Qtronic_Demo_LGen_CT
+return boolean
+{
+ var charstring vl_param := "sip:127.0.0.1:5061";
+
+ if (pl_ptr.reportedEvent.event.bIdx == v_SIP_myBIdx and
+ pl_ptr.reportedEvent.event.iIdx == c_SIP_eventIdx_INVITE)
+ {
+ var integer vl_FSMIdx := -1;
+ pl_ptr.refContext.fCtxIdx := 0;
+
+ if (not f_EPTF_SIP_FSMInitialized(pl_ptr.eIdx,
+ pl_ptr.refContext.fCtxIdx, vl_FSMIdx))
+ {
+ f_SIP_step_init(pl_ptr);
+ f_SIP_step_handleINVITE(pl_ptr);
+ }
+ netIn.send(SIPReq:{"INVITE", vl_param});
+ }
+ else if (pl_ptr.reportedEvent.event.bIdx == v_SIP_myBIdx
+ and pl_ptr.reportedEvent.event.iIdx == c_SIP_eventIdx_ACK)
+ {
+ netIn.send(SIPReq:{"ACK", vl_param});
+ }
+ else if (pl_ptr.reportedEvent.event.bIdx == v_SIP_myBIdx and
+ pl_ptr.reportedEvent.event.iIdx == c_SIP_eventIdx_BYE)
+ {
+ netIn.send(SIPReq:{"BYE", vl_param});
+ }
+ else if (pl_ptr.reportedEvent.event.bIdx == v_SIP_myBIdx and
+ pl_ptr.reportedEvent.event.iIdx == c_SIP_eventIdx_CANCEL)
+ {
+ netIn.send(SIPReq:{"CANCEL", vl_param});
+ }
+ // . . .
+ else
+ {
+ log(%definitionId & "(): unhandled incoming message");
+ }
+ return false;
+ }
+ Return true;
+}
+----
+=== Workflow
+
+The work process can be outlined in the following steps:
+
+* Modeling
+** Identify the interfaces of the model
+** Create the model in Qtronic
+* Test Harness Implementation
+** Create the Test Harness component
+*** Put all required component types together
+*** Write the initialization code
+*** Plan the mappings between the Model interface and the Applibs’ interfaces
+*** Write the mapping code
+** Write the configuration functions
+*** `beginTestCase`
+*** `endTestCase`
+* Build the Executable Test Suite
+** Export the TTCN-3 code generated with the TTCN-Scripter
+** Create the project file with all TTCN sources
+** Build the project
+* Test Execution
+** Write the TITAN configuration file
+** Execute the Test
+* Analyze the test results.
+
+=== TTCNScripter v2.1.1 Settings
+
+The settings for the TTCNScripter plugin for Qtronic v2.1.1 used for this demo can be seen in the following figures:
+
+image::images/tsmain.jpeg[title="TTCNScripter: Main Panel"]
+
+image::images/tscustom.jpeg[title="TTCNScripter: Customization Panel"]
+
+image::images/tsextension.jpeg[title="TTCNScripter: Extensions Panel"]
+
+image::images/tsapplib.jpeg[title="TTCNScripter: EPTF_MBT_Applib Panel"]
+
+== MBT Applib Demo with Qtronic Using Applib PDUs
+
+In this demo we modify the SIP Phone model that is shipped with Qtronic and was used in the <<SUT_SIP_Phone, previous example>> so that it will use TitanSim test steps and events directly. Therefore, no user mapping code is needed.
+
+[[demo-files-0]]
+=== Demo Files
+
+The demo consists of the following files:
+
+* Qtronic Model of the SUT
+** The SUT Behavior
+*** _demo/direct/model/SIPClient.java_
+*** _demo/direct/model/SIPClient.xmi_
+** Java definitions of the TitanSim API:
+*** __src/Qtronic/model/EPTF_MBT_Framework.java__
+*** __src/Qtronic/model/EPTF_MBT_SIP_Applib.java__
+* User written files
+** __Demo/direct/MBT_Qtronic_Demo.prj__ +
+ Project file that build the whole project.
+** __Demo/direct/MBT_Qtronic_Demo.cfg__ +
+ Sample config file to be able to execute the testcases.
+** __Demo/direct/MBT_Qtronic_Demo.ttcn__ +
+ User written code for initialization, configuration and mapping.
+* Generated files by Qtronic
+** __Demo/direct/MBT_Qtronic_Testcases.ttcn__ +
+ This contains the generated testcases.
+** __Demo/direct/MBT_Qtronic_TestHarness.ttcn__ +
+ The send/receive functions can be found here.
+** __Demo/direct/MBT_Qtronic_Types.ttcn__ +
+ The generated type definitions for the abstract test data.
+* TTCN-3 Scripter
+** __Demo/TTCNScripter/TTCNScripter_v211.jar__
+
+[[test-arrangement-overview-0]]
+=== Test Arrangement Overview
+
+The demo’s overview picture can be found in the figure below. There are three main actors: the Tester, which executes the abstract test; the Test Harness, which provides the mapping between the abstract test data and a real-life test PDU; and finally the System Under Test.
+
+The notable difference between this and the mapped demo is that the user does not need to implement the "mapping" layer in the Test Harness. Instead, some TitanSim API definitions are included in the model, and the model communicates with only those abstract data definitions, that are allowed there.
+
+image::images/Qtronic_Direct_Demo_Overview.png[title="Qtronic Direct Demo Overview"]
+
+
+Consequently everything described in <<MBT_Applib_Demo_with_Qtronic_Using_User-Defined_Messages, MBT Applib Demo with Qtronic Using User-Defined Messages>> applies here as well, except for the mapping functions, because they are not needed now.
+
+=== Modeling with TitanSim API
+
+The Qtronic model must be modified, so that it can communicate with MBT Applib primitives:
+
+[source]
+----
+system
+{
+ Inbound userIn : UserInput;
+ Outbound userOut : TimeOutIndication;
+ Inbound fwIn : EPTF_MBT_TestStepRequest;
+ Outbound fwOut : EPTF_MBT_TestStepResponse;
+}
+----
+
+Message sending in the model is done via separate functions. For example, in figure below there is a transition from the Init state to the Calling state. When this transition is executed it calls the `Invite()` model function, which will send out a SIP INVITE abstract test message.
+
+The `Invite()` function will send out an EPTF MBT Applib `TestStepResponse` primitive to the model environment. During test generation it will be mapped to a message receive statement, where the Tester expects a `TestStepResponse` message from the Test Harness:
+
+[source]
+----
+public void Invite() {
+ EPTF_MBT_TestStepResponse r; = c_EPTF_MBT_TestStepResponse_empty();
+ r.bName = c_SIP_Behavior;
+ r.iName = c_SIP_eventName_INVITE;
+ fwOut.send(r, 1.0); }
+----
+
+image::images/Model_fragment_in_Qtronic_with_the_direct_approach.png[title="Model fragment in Qtronic with the direct approach"]
+
+Message reception is also implemented using CQL functions in the model. When we have an incoming 180 response in the Calling state we will go to the Ringing state:
+
+[source]
+----
+fwIn: EPTF_MBT_TestStepRequest
+ [msg == incomingResponse(180)]/
+require true;
+----
+
+The `incomingResponse()` model function is using the `EPTF_MBT_TestStepRequest` MBT Applib primitive to call a `createResponse` SIP Applib test step:
+
+[source]
+----
+public EPTF_MBT_TestStepRequest incomingResponse(int p_answerCode)
+ {
+ EPTF_MBT_TestStepRequest r; = c_EPTF_MBT_TestStepRequest_empty();
+ r.stepName = c_SIP_stepFunction_createResponse;
+ r.stepArgs =
+ {
+ f_EPTF_SIP_mapAnswerCode2SipTemplateCode(p_answerCode)
+ };
+ r.addr.entityGroupName = "MBT_EntityType";
+ r.addr.eIdx = 0;
+ r.addr.fIdx = 0;
+
+ return r;
+}
+----
+
+With this modeling approach the generated testcases will always use the EPTF MBT Applib primitives to communicate with the test harness.
+
+== Demo with Spec Explorer Using User-Defined Messages
+
+The goal of this demo is to create a project in Spec Explorer which is able to generate a functionally same code as Qtronic does. Thus the operation and structure are not detailed in this passage due to similarity.
+
+=== Generating TTCN Code in Spec Explorer
+
+Spec Explorer originally does not support TTCN code generation. So, some additional classes are needed to do that. The operation in short is that test cases generated by Spec Explorer invoke the methods of these classes, so during the running they indirectly write TTCN code in a separate file. The correctness of this TTCN code is the tester’s responsibility. Spec Explorer checks the success of its own test cases only, the generated ones can be checked with TITAN. This whole procedure looks like as a double test case generation, one for Spec Explorer and one for TITAN.
+
+[[export2ttcn-cs]]
+=== _Export2TTCN.cs_
+
+_Export2TTCN.cs_ contains the necessary classes to export TTCN code from Spec Explorer. It implements the Export2TTCN namespace, which contains two classes, see figure below:
+
+image::images/Class_FileExport.PNG[title="Class FileExport"]
+
+This is a universal class for writing files with indentation handling (`ind_p` increases, `ind_n` decreases indent). Test cases must be written by 2 specialized methods: `write_tc` and `dump_tc`.
+
+TTCNExporter is an abstract class for writing TTCN files. It has 6 abstract methods to be configurable:
+
+image::images/Class TTCNExporter.PNG[title="Class TTCNExporter"]
+
+
+=== The Procedure of Creating a New Project
+
+* *File > New > Project* –> choose *Visual C# > Test > Spec Explorer Base Solution* +
+Set parameters (name, path etc.) +
+Choose Static modeling solution
+* Implement _Adapter.cs_ using prepared class(es) (TTCNExporter) +
+Override abstract methods
+* Implement _Model.cs_ +
+Declare necessary actions
+* Implement _Config.coord_ +
+Declare actions and switches in the config Main +
+Create machines, especially the three main machines (construct model program, synchronizing, construct test cases)
+* In the Exploration Manager select Testsuite machine (which creates test cases) and click on Generate Test Code
+* On the Test Tools Toolbar click on the "Run All Tests in Solution"
+
+=== FSM Implementation Techniques
+
+image::images/FSM_1.png[title="FSM 1"]
+
+This simple figure shows three states and two transitions. S1 is a start state, the others are accepting states.
+
+Spec Explorer does not support drawing models, so it has to be written as a program. First of all create a machine for each state:
+
+[source]
+----
+Machine S1() : ConfigName
+{}
+Machine S2() : ConfigName
+{}
+Machine S3() : ConfigName
+{}
+----
+
+The body of machines contains the outgoing transitions, which can be accomplished as pairs of actions and states. For example (T1() ; S2()) | (T2() ; S3()). Semicolon means sequence, and pipe means "or". Thus the next step from S1 is to execute T1 and go on into S2 or T2 and go on into S3. The final code of S1:
+
+[source]
+----
+Machine S1() : ConfigName
+{ (T1() ; S2()) | (T2() ; S3()) }
+----
+
+image::images/FSM_2.png[title="FSM 2"]
+
+The figure above is a bit more complicated. There is a cycle in the model. Spec Explorer does not support cyclic references between machines so we have to use something else. The problem can be treated with using * operator, for example A* means: repeats A zero or more times. One solution:
+
+[source]
+----
+Machine S1() : ConfigName
+{ (T1() ; S2()) | (T2() ; (T3() ; T4())* ; S3()) }
+Machine S2() : ConfigName
+{}
+Machine S3() : ConfigName
+{ T3() ; S4() }
+Machine S4() : ConfigName
+{}
+----
+
+[[demo-files-1]]
+=== Demo Files
+
+The project consists of three main files: _Adapter.cs_, _Model.cs_, _Config.cord_.
+
+_Adapter.cs_ contains two classes: NewExporter and Adapter. NewExporter is the real exporter class, it is inherited from TTCNExporter whose abstract methods are implemented by overriding them. Adapter is a static class, its methods are the implementation of transitions from FSM.
+
+Example:
+
+[source]
+----
+using System;
+using System.Collections.Generic;
+using System.Text;
+using Export2TTCN;
+
+namespace MBT.Adapter
+{
+ public class NewExporter : TTCNExporter
+ {
+ public NewExporter(string p_modulename,string p_path)
+ :base(p_modulename,p_path) {}
+
+ protected override void write_imports() {…}
+
+ protected override void write_types() {…}
+
+ protected override void write_altsteps() {…}
+
+ protected override void write_else() {…}
+
+ public void send(string command, string message)
+ { write_tc(command + "(" + message + ");");}
+
+ public void receive(string command, string message, double wait)
+ {write_tc("-timername-.start(" + wait.ToString("F2") + " + SLACK);");
+ write_tc("log(\"Waiting for: " + message + "\");");
+ write_tc(command + "(" + message + ");");
+ write_tc("-timername-.stop;");
+ }
+
+ protected override void beginning_tc() {…}
+
+ protected override void ending_tc() {…}
+ }
+
+ public static class Adapter
+ {
+ private static NewExporter exporter =
+ new NewExporter("MBT_SpecExpl_Testcases", "C:/path..");
+
+ public static void start()
+ { exporter.start(); }
+
+ public static void end()
+ { exporter.end(); }
+
+ public static void Transition_name() {…send,receive…}
+ }}
+----
+
+
+_Model.cs_ contains only one class: ModelProgram. The model can be programmed by this class. For example conditions can be set at transitions (actions). In this demo there was no need to use more than an empty program.
+
+Example:
+
+[source]
+----
+using System;
+using System.Collections.Generic;
+using System.Text;
+using System.Linq;
+
+using Microsoft.Modeling;
+
+namespace MBT.Model
+{
+ static class ModelProgram
+ {
+ [Action]
+ static void start() {}
+ [Action]
+ static void Init_Calling() {}
+ [Action]
+ static void Calling_Ringing() {}
+ [Action]
+ static void Terminating_OK() {}
+ [Action]
+ static void Terminating_Timeout() {}
+ [Action]
+ static void end() {}
+ }
+}
+----
+
+_Config.cord_ can be divided into two main passages: configurations and machines. Configurations are used to control exploration and test generation. One of their purposes is to define the actions on which the model is based. This set of actions represents steps in a model trace or in the execution of an implementation. A configuration can also include a set of switches and parameters to control exploration and testing. Example:
+
+[source]
+----
+using MBT.Adapter;
+config Main
+{
+ action abstract static void Adapter.start();
+ action abstract static void Adapter.end();
+ action abstract static void Adapter.Init_Calling();
+
+ switch StepBound = 1024;
+ switch PathDepthBound = 1024;
+ switch StateBound = 1024;
+ switch TestClassBase = "vs";
+ switch GeneratedTestPath = "..\\TestSuite";
+ switch GeneratedTestNamespace = "MBT.TestSuite";
+ switch TestEnabled = false;
+ switch ForExploration = false;
+}
+
+machine Model() : Main where ForExploration = true
+{ Model_CLOSED_START()* }
+----
+
+Instead of states and transitions, FSM is modeled by machines. A machine can invoke another one or an action. So in every machine a pair of action and machine means a transition to a new state.
+
+There are three main machines that must not be missed:
+
+[source]
+----
+machine ModelProgram() : Main
+{ construct model program from Main
+ where namespace = "MBT.Model" }
+----
+
+This construct builds a behavior from a model program. The identifier is a required configuration name, which defines the actions to which the model program is bound.
+
+[source]
+----
+machine Model_Sync() : Main where ForExploration = true
+{Model || ModelProgram}
+----
+
+This machine synchronizes Model and ModelProgram.
+
+[source]
+----
+machine Testsuite() : Main where ForExploration = true, TestEnabled = true
+{ construct test cases
+ where AllowUndeterminedCoverage = true
+ for Model_Sync }
+----
+
+This machine creates the test cases.
+
+=== Exploration
+
+Exploration is an operation by which Spec Explorer systematically discovers all possible states defined by a model, and the steps to transition from one state to another. The unit of exploration in Spec Explorer is a machine. Machines are defined in Cord scripts and each machine is based on one or more configurations. Configurations declare the set of actions that can be used to lebel steps, together with switches that control the exploration process. The result of an exploration is an Exploration Graph, which is displayed in the Exploration Graph Viewer.
+
+image::images/model.png[title="Exploration of Model machine"]
+
+Exploration of Model machine shows the whole model. This is a mass of cycles starting with start() method and always ending with end(). These two methods are necessary to initialize and close each test case.
+
+image::images/modelsync.png[title="Exploration of Model_Sync machine"]
+
+This is the same as the first one, because ModelProgram in Model.cs is only a skeleton, actually it is empty.
+
+image::images/testsuite.png[title="Exploration of Testsuite machine"]
+
+Testsuite machine generates test cases from the model. The figure shows seven generated test cases with states and actions.
+
+= Test Harness with MBT applib for GGSN MBT Pilot Project
+
+This section provides a quick introduction for the Test Harness developed for the MBT GGSN Pilot Project.
+
+== Demo Files
+
+The demo consists of the following files:
+
+* Qtronic Model of the GGSN SUT
+** _demo/ggsn/model/CDRrecords.java_
+** _demo/ggsn/model/charging.java_
+** _demo/ggsn/model/cli.java_
+** _demo/ggsn/model/CLIrecords.java_
+** _demo/ggsn/model/configuration.java_
+** _demo/ggsn/model/GGSN.java_
+** _demo/ggsn/model/GGSN.xmi_
+** _demo/ggsn/model/globals.java_
+** _demo/ggsn/model/GTPrecords.java_
+** _demo/ggsn/model/prepareRestore.java_
+** _demo/ggsn/model/RadiusRecords.java_
+** _demo/ggsn/model/system.java_
+** _demo/ggsn/model/UDPrecords.java_
+
+* User written files
+** _demo/ggsn/MBT_Qtronic_Demo.prj_
++
+Project file that builds the whole project.
+
+** _demo/ggsn/MBT_Qtronic_Demo.cfg_
++
+Sample config file to be able to execute the testcases.
+
+** _demo/MBT_Qtronic_Main.ttcn_
++
+User written code for initialization, configuration and mapping.
+
+* Generated files by Qtronic
+** _demo/MBT_Qtronic_Testcases.ttcn_
++
+This contains the generated testcases.
+
+** _demo/MBT_Qtronic_TestHarness.ttcn_
++
+The send/receive functions can be found here.
+
+** _demo/MBT_Qtronic_TestSystem.ttcn_
++
+The main component types are defined here.
+
+** _demo/MBT_Qtronic_Types.ttcn_
++
+The generated type definitions for the abstract test data.
+
+* TTCN-3 Scripter
+** _demo/TTCNScripter/TTCNScripter_v421.jar_
+
+== Workflow
+
+We used the same workflow depicted in <<fig_2, Figure 2>>. In the following subsections we describe each step in detail.
+
+=== Creating the Model
+
+The workflow is started with creating the model. Modelling can be decomposited to two main steps:
+
+** Planning the framework model interface: describing the types and primitives on this interface
+** Defining the dynamic behavior of the model, using the already decided interface.
+
+In our example project the model can be found in the model directory.
+
+=== Generating the Test Cases
+
+The model is then loaded into the Conformiq Qtronic tool, the coverage criteria were set up. In *Qtronic* > *Project’s Properties* > *Conformiq Options*, we have made the following test generation settings:
+
+* Only finalized runs was turned on
+* The Look ahead depth was set to level 3
+
+image::images/Figure_26_Qtronics_Test_Generation_Settings.png[title="Qtronic's Test Generation Settings"]
+
+After applying these settings we generated the abstract test cases using the the *Generate Tests* feature and in our case we got 10 testcases.
+
+image::images/Figure_27_The_Generated_Test_Cases.png[title="The Generated Test Cases"]
+
+We have added our TTCN-3 scripter to the project using *Project* > *DC1* > *New* > *Scripting backend*. The TTCNScripter can be found in the _TTCNScripter/TTCNScripterv_421.jar_ directory.
+Before generating the TTCN-3 modules for the abstract test cases the TTCN3-Scripter must be configured. The settings we used can be seen below.
+
+image::images/Figure_28_TTCNScripter_Main_Tab_Settings.png[title="TTCNScripter Main Tab Settings"]
+
+image::images/Figure_29_TTCNScripter_Customization_Tab_Settings.png[title="TTCNScripter Customization Tab Settings"]
+
+image::images/Figure_30_TTCNScripter_Timing_Tab_Settings.png[title="TTCNScripter Timing Tab Settings"]
+
+image::images/Figure_31_TTCNScripter_Logging_Tab_Settings.png[title="TTCNScripter Logging Tab Settings"]
+
+image::images/Figure_32_TTCNScripter_Extension_Tab_Settings.png[title="TTCNScripter Extension Tab Settings"]
+
+image::images/Figure_33_TTCNScripter_EPTF_MBT_Applib_Tab_Settings.png[title="TTCNScripter EPTF_MBT_Applib Tab Settings"]
+
+Further information on the meaning of these parameters can be found in the FS.
+After the TTCNScripter has been properly configured the TTCN-3 modules for the abstract tests can be generated using the *Render Tests* action in Qtronic. As a result the following files are generated:
+
+* _MBT_Qtronic_Testcases.ttcn_
+* _MBT_Qtronic_TestHarness.ttcn_
+* _MBT_Qtronic_TestSystem.ttcn_
+* _MBT_Qtronic_Types.ttcn_
+
+=== Test Script FrameworkNext, the test script framework must be implemented.
+
+image::images/Figure_34_Framework_Overview.png[title="Framework Overview"]
+
+The framework consists of
+
+* Application Libraries
+* Mapping code
+
+The mapping code is project specific. It is implemented in the following files:
+
+* _MBT_Qtronic_Main.ttcn_
+** Init functions
+** Mapping functions
+* _MBT_Qtronic_TestHarness.ttcn_
+** For each test harness send receive function generated by the TTCNScripter the corresponding mapping function in _MBT_Qtronic_Main.ttcn_ must be called.
+
+After the framework sources are ready. It must be compiled and linked with the abstract test suite, thus an executable test suite is produced.
+
+=== Executing the Test Suite
+
+To execute the test suite a configuration file is needed (besides the binary executable test suite).
+
+An example configuration file is provided in the _MBT_demo.cfg_. The configuration file has inline comments, detailed description about the module parameters can be found in the application libraries’ apidoc and UG documentation.
+
+The command to execute the test suite is:
+
+[source]
+$> ttcn3_start ./bin/demo ./MBT_Qtronic_Demo.cfg
+
+Thus we executed the test cases against the SUT and the results and logs are saved.
+
+== Test Harness
+
+=== Internal Structure
+
+The demo’s overview picture can be found in <<fig_35, Figure 35>>. There are two main actors: the Tester, which executes the abstract test; and the Test Harness, which provides the mapping between the abstract test data and a real-life test PDU.
+
+The Tester controls the Test Harness. It is built mostly from generated code, the only exceptions are the functions that are responsible for creating and connecting the components.
+
+The Test Harness contains the needed application libraries. On top of these is the user mapping code, which must implement the mapping between the application library API and the abstract test data.
+
+[[fig_35]]
+image::images/Figure_35_Component_Overview.png[title="Component Overview"]
+
+NOTE: in the source code the QtronicCT extends the _MBT_Qtronic_Main_CT_ component. Therefore the Tester and TestHarness are actually on the same PTC.
+
+=== Mapping
+The mapping is implemented in the _MBT_Qtronic_Main.ttcn_ module. It consists of several parts:
+
+* Init functions
+** `f_cq_beginTestcase()`
++
+It creates and connects and initializes the components in the beginning of each test case.
+
+** `f_cq_endTestcase()`
++
+It cleans up and shuts down the component structure created for the testcase.
+
+* Mapping
+** Tester → Test Harness
++
+The abstract messages incoming from the Tester component must be mapped to TitanSim Applib API calls. For each message there is a separate handle function:
+
+*** `f_Model_sendCreatePDPContext(in CreatePDPcontext p_CreatePDPcontext)`
+*** `f_Model_sendUpdatePDPContext(in UpdatePDPcontext p_UpdatePDPcontext)`
+*** `f_Model_sendDeletePDPContext(in DeletePDPcontext p_DeletePDPcontext)`
+*** `f_Model_sendGPDU(in GPDU p_gpdu)`
+*** `f_Model_sendUDPpdu(in UDPpdu p_UDPpdu)`
+
+** Test Harness → Tester
++
+The messages coming from the SUT will result in event dispatches in the application libraries. The MBT application library will catch these events and will call a function which is responsible to map the incoming real life messages to the model’s abstract messages:
+
+*** `f_MBT_Demo_LGen_createUserMessage(in EPTF_LGenBase_TestStepArgs pl_ptr)`
+
+* Utility functions
++
+These functions are mainly for converting the parameters between two representations (because sometimes the applib represents data in a different format than the model):
+
+** `f_getAPN_char2oct(in charstring p_apn)`
+** `f_getIMSI_str2hex(in charstring p_imsi_str)`
+** `f_getMSISDN_str2hex(in charstring p_imsi_str)`
+** `f_str2tbcd(in charstring p_str)`
+
+= Terminology
+
+*TitanSim Core (Load) Library(CLL):* +
+It is that part of the TitanSim software that is totally project independent. (I.e., which is not protocol-, or application-dependent). The TitanSim CLL is to be supplied and supported by the TCC organization. Any TitanSim CLL development is to be funded centrally by Ericsson.
+
+*TitanSim Appliaction Library:* +
+It is the application-specific part of the TitanSim software. It provides load generation functionalities belonging to specific protocols or products.
+
+== System Requirements
+
+Application libraries are a set of TTCN-3 source code files that can be used as part of TTCN-3 test suites only. Hence, application libraries alone do not put specific requirements on the system used. However in order to compile and execute a TTCN-3 test suite using the set of application libraries the following system requirements must be satisfied:
+
+* TITAN TTCN-3 Test Executor <<_2, [2]>> version 1.7.pl2 installed.
+
+= Abbreviations
+
+Applib:: Application Library
+
+CLL:: Core Load Library
+
+EPTF:: Ericsson Performance Test Framework
+
+FSM:: Finite State Machine
+
+MBT:: Model Based Testing
+
+MSC:: Message Sequence Chart
+
+TTCN-3:: Test and Test Control Notation version 3
+
+SUT:: System Under Test
+
+TitanSim:: New synonym for the EPTF framework
+
+= References
+
+[[_1]]
+[1] ETSI ES 201 873-1 v3.2.1 (2007-02) The Testing and Test Control Notation version 3. Part 1: Core Language
+
+[[_2]]
+[2] User Guide for the TITAN TTCN-3 Test Executor
+
+[[_3]]
+[3] EPTF Applib MBT for TitanSim, Function Specification
+
+[[_4]]
+[4] EPTF MBT Application Library for TTCN-3 Toolset with TITAN, Reference Guide +
+Alternatively, please consult the doc/apidoc directory of the released application library.
+
+[[_5]]
+[5] Spec Explorer 2010 Help
+
+[[_6]]
+[6] Conformiq Qtronic +
+www.conformiq.com
diff --git a/doc/UG/EPTF AppLib MBT for TitanSim, User Guide.pdf b/doc/UG/EPTF AppLib MBT for TitanSim, User Guide.pdf
new file mode 100644
index 0000000..0c55ff2
--- /dev/null
+++ b/doc/UG/EPTF AppLib MBT for TitanSim, User Guide.pdf
Binary files differ
diff --git a/doc/UG/change.log b/doc/UG/change.log
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/doc/UG/change.log
diff --git a/doc/UG/images/Class TTCNExporter.PNG b/doc/UG/images/Class TTCNExporter.PNG
new file mode 100644
index 0000000..797bbb3
--- /dev/null
+++ b/doc/UG/images/Class TTCNExporter.PNG
Binary files differ
diff --git a/doc/UG/images/Class_FileExport.PNG b/doc/UG/images/Class_FileExport.PNG
new file mode 100644
index 0000000..ba70d17
--- /dev/null
+++ b/doc/UG/images/Class_FileExport.PNG
Binary files differ
diff --git a/doc/UG/images/Component_Arrangement_in_the_simple_demo.png b/doc/UG/images/Component_Arrangement_in_the_simple_demo.png
new file mode 100644
index 0000000..975e905
--- /dev/null
+++ b/doc/UG/images/Component_Arrangement_in_the_simple_demo.png
Binary files differ
diff --git a/doc/UG/images/FSM_1.png b/doc/UG/images/FSM_1.png
new file mode 100644
index 0000000..7ffaa18
--- /dev/null
+++ b/doc/UG/images/FSM_1.png
Binary files differ
diff --git a/doc/UG/images/FSM_2.png b/doc/UG/images/FSM_2.png
new file mode 100644
index 0000000..8e0cba6
--- /dev/null
+++ b/doc/UG/images/FSM_2.png
Binary files differ
diff --git a/doc/UG/images/Figure_26_Qtronics_Test_Generation_Settings.png b/doc/UG/images/Figure_26_Qtronics_Test_Generation_Settings.png
new file mode 100644
index 0000000..68d6159
--- /dev/null
+++ b/doc/UG/images/Figure_26_Qtronics_Test_Generation_Settings.png
Binary files differ
diff --git a/doc/UG/images/Figure_27_The_Generated_Test_Cases.png b/doc/UG/images/Figure_27_The_Generated_Test_Cases.png
new file mode 100644
index 0000000..3343bf7
--- /dev/null
+++ b/doc/UG/images/Figure_27_The_Generated_Test_Cases.png
Binary files differ
diff --git a/doc/UG/images/Figure_28_TTCNScripter_Main_Tab_Settings.png b/doc/UG/images/Figure_28_TTCNScripter_Main_Tab_Settings.png
new file mode 100644
index 0000000..114db6b
--- /dev/null
+++ b/doc/UG/images/Figure_28_TTCNScripter_Main_Tab_Settings.png
Binary files differ
diff --git a/doc/UG/images/Figure_29_TTCNScripter_Customization_Tab_Settings.png b/doc/UG/images/Figure_29_TTCNScripter_Customization_Tab_Settings.png
new file mode 100644
index 0000000..db371b8
--- /dev/null
+++ b/doc/UG/images/Figure_29_TTCNScripter_Customization_Tab_Settings.png
Binary files differ
diff --git a/doc/UG/images/Figure_30_TTCNScripter_Timing_Tab_Settings.png b/doc/UG/images/Figure_30_TTCNScripter_Timing_Tab_Settings.png
new file mode 100644
index 0000000..b8d22a5
--- /dev/null
+++ b/doc/UG/images/Figure_30_TTCNScripter_Timing_Tab_Settings.png
Binary files differ
diff --git a/doc/UG/images/Figure_31_TTCNScripter_Logging_Tab_Settings.png b/doc/UG/images/Figure_31_TTCNScripter_Logging_Tab_Settings.png
new file mode 100644
index 0000000..d8800bb
--- /dev/null
+++ b/doc/UG/images/Figure_31_TTCNScripter_Logging_Tab_Settings.png
Binary files differ
diff --git a/doc/UG/images/Figure_32_TTCNScripter_Extension_Tab_Settings.png b/doc/UG/images/Figure_32_TTCNScripter_Extension_Tab_Settings.png
new file mode 100644
index 0000000..221f9e7
--- /dev/null
+++ b/doc/UG/images/Figure_32_TTCNScripter_Extension_Tab_Settings.png
Binary files differ
diff --git a/doc/UG/images/Figure_33_TTCNScripter_EPTF_MBT_Applib_Tab_Settings.png b/doc/UG/images/Figure_33_TTCNScripter_EPTF_MBT_Applib_Tab_Settings.png
new file mode 100644
index 0000000..90abcbf
--- /dev/null
+++ b/doc/UG/images/Figure_33_TTCNScripter_EPTF_MBT_Applib_Tab_Settings.png
Binary files differ
diff --git a/doc/UG/images/Figure_34_Framework_Overview.png b/doc/UG/images/Figure_34_Framework_Overview.png
new file mode 100644
index 0000000..7d5cdbe
--- /dev/null
+++ b/doc/UG/images/Figure_34_Framework_Overview.png
Binary files differ
diff --git a/doc/UG/images/Figure_35_Component_Overview.png b/doc/UG/images/Figure_35_Component_Overview.png
new file mode 100644
index 0000000..8b2a3ab
--- /dev/null
+++ b/doc/UG/images/Figure_35_Component_Overview.png
Binary files differ
diff --git a/doc/UG/images/General_workflow_with_MBT.png b/doc/UG/images/General_workflow_with_MBT.png
new file mode 100644
index 0000000..f169bed
--- /dev/null
+++ b/doc/UG/images/General_workflow_with_MBT.png
Binary files differ
diff --git a/doc/UG/images/Model-Based Testing.png b/doc/UG/images/Model-Based Testing.png
new file mode 100644
index 0000000..c67d0b1
--- /dev/null
+++ b/doc/UG/images/Model-Based Testing.png
Binary files differ
diff --git a/doc/UG/images/Model_fragment_in_Qtronic_with_the_direct_approach.png b/doc/UG/images/Model_fragment_in_Qtronic_with_the_direct_approach.png
new file mode 100644
index 0000000..9595ee8
--- /dev/null
+++ b/doc/UG/images/Model_fragment_in_Qtronic_with_the_direct_approach.png
Binary files differ
diff --git a/doc/UG/images/Qtronic modeler.png b/doc/UG/images/Qtronic modeler.png
new file mode 100644
index 0000000..e2db5b6
--- /dev/null
+++ b/doc/UG/images/Qtronic modeler.png
Binary files differ
diff --git a/doc/UG/images/Qtronic perspective in Eclipse.png b/doc/UG/images/Qtronic perspective in Eclipse.png
new file mode 100644
index 0000000..d1ed31f
--- /dev/null
+++ b/doc/UG/images/Qtronic perspective in Eclipse.png
Binary files differ
diff --git a/doc/UG/images/Qtronic_Demo_Component_Structure.png b/doc/UG/images/Qtronic_Demo_Component_Structure.png
new file mode 100644
index 0000000..759f60a
--- /dev/null
+++ b/doc/UG/images/Qtronic_Demo_Component_Structure.png
Binary files differ
diff --git a/doc/UG/images/Qtronic_Direct_Demo_Overview.png b/doc/UG/images/Qtronic_Direct_Demo_Overview.png
new file mode 100644
index 0000000..2b373a2
--- /dev/null
+++ b/doc/UG/images/Qtronic_Direct_Demo_Overview.png
Binary files differ
diff --git a/doc/UG/images/SUT_SIP_Phone.png b/doc/UG/images/SUT_SIP_Phone.png
new file mode 100644
index 0000000..933defd
--- /dev/null
+++ b/doc/UG/images/SUT_SIP_Phone.png
Binary files differ
diff --git a/doc/UG/images/Simple_Demo_Signaling.png b/doc/UG/images/Simple_Demo_Signaling.png
new file mode 100644
index 0000000..1a413d4
--- /dev/null
+++ b/doc/UG/images/Simple_Demo_Signaling.png
Binary files differ
diff --git a/doc/UG/images/Spec Explorer in Visual Studio.png b/doc/UG/images/Spec Explorer in Visual Studio.png
new file mode 100644
index 0000000..4ca4c5c
--- /dev/null
+++ b/doc/UG/images/Spec Explorer in Visual Studio.png
Binary files differ
diff --git a/doc/UG/images/Test harness role.png b/doc/UG/images/Test harness role.png
new file mode 100644
index 0000000..480a407
--- /dev/null
+++ b/doc/UG/images/Test harness role.png
Binary files differ
diff --git a/doc/UG/images/TitanSim-Based_Test_Harness.png b/doc/UG/images/TitanSim-Based_Test_Harness.png
new file mode 100644
index 0000000..c89ff5d
--- /dev/null
+++ b/doc/UG/images/TitanSim-Based_Test_Harness.png
Binary files differ
diff --git a/doc/UG/images/model.png b/doc/UG/images/model.png
new file mode 100644
index 0000000..eb907c4
--- /dev/null
+++ b/doc/UG/images/model.png
Binary files differ
diff --git a/doc/UG/images/modelsync.png b/doc/UG/images/modelsync.png
new file mode 100644
index 0000000..eb907c4
--- /dev/null
+++ b/doc/UG/images/modelsync.png
Binary files differ
diff --git a/doc/UG/images/se_workflow.png b/doc/UG/images/se_workflow.png
new file mode 100644
index 0000000..817ada2
--- /dev/null
+++ b/doc/UG/images/se_workflow.png
Binary files differ
diff --git a/doc/UG/images/testsuite.png b/doc/UG/images/testsuite.png
new file mode 100644
index 0000000..5cb114a
--- /dev/null
+++ b/doc/UG/images/testsuite.png
Binary files differ
diff --git a/doc/UG/images/tsapplib.jpeg b/doc/UG/images/tsapplib.jpeg
new file mode 100644
index 0000000..49f80d3
--- /dev/null
+++ b/doc/UG/images/tsapplib.jpeg
Binary files differ
diff --git a/doc/UG/images/tscustom.jpeg b/doc/UG/images/tscustom.jpeg
new file mode 100644
index 0000000..01710fe
--- /dev/null
+++ b/doc/UG/images/tscustom.jpeg
Binary files differ
diff --git a/doc/UG/images/tsextension.jpeg b/doc/UG/images/tsextension.jpeg
new file mode 100644
index 0000000..c228828
--- /dev/null
+++ b/doc/UG/images/tsextension.jpeg
Binary files differ
diff --git a/doc/UG/images/tsmain.jpeg b/doc/UG/images/tsmain.jpeg
new file mode 100644
index 0000000..c35a8fc
--- /dev/null
+++ b/doc/UG/images/tsmain.jpeg
Binary files differ
