Google Git
Sign in
eclipse / titan / titan.Libraries.CLL / 10acbe6e6ef8985636be25db8d4ff5b2aea681b1 / . / doc / ExecCtrl / UG / EPTF_CLL_ExecCtrl_User_Guide.adoc
blob: 4d580ff3836b3745954517998916194ffd8be2c0 [file] [log] [blame]
---
Author: József Gyürüsi
Version: 19/198 17-CNL 113 512, Rev. K
Date: 2017-06-12
---
= EPTF Core Library Execution Control, User Guide
:author: József Gyürüsi
:revnumber: 19/198 17-CNL 113 512, Rev. K
:revdate: 2017-06-12
:toc:
== System Requirements
In order to use the `ExecCtrl` feature the system requirements listed in EPTF Core Library User Guide <<_4, [4]>> should be fulfilled.
= Execution Control
== Overview
The EPTF Core Library `ExecCtrl` in connection with `ExecCtrlClient` components are fundamental components providing an implementation for traffic case execution control in a TitanSim-based load test environment. `ExecCtrl` provides central configuration and execution control support when using multiple, even different types of Load Generators during parallel test execution.
The `ExecCtrl` feature is designed to control and distribute the traffic case execution on several `LGens`. This makes possible to execute the same test using more CPUs. The management and synchronization of the `LGen` components is the main role of the `ExecCtrl` feature.
The `ExecCtrl` component is able to deploy the `LGen` components that execute the traffic cases automatically. It uses user written `LGen` creator functions that are registered into `ExecCtrl` to create the `LGens`. The `LGens` can be organized into groups. These groups are called `LGen`-pools. A scenario, which is basically a list of traffic cases, is executed only on the `LGens` of a single `LGen` pool. This makes the configuration easily manageable.
`ExecCtrl` supports multiple phase execution. This means that several scenarios can be organized into groups with a given phase list. The execution of the scenarios in these scenario groups is repeated for every phase in the phase list in sequential order. The next phase is only started when all scenarios finished their execution in the current phase. This functionality can be used to synchronize the execution of different scenarios, and to make possible phase dependent scenario and traffic case execution.
`ExecCtrl` can be configured with the help of module parameters. It uses the same module parameters as `LGenBase` uses to declare scenarios, entity groups and traffic cases, but has its own module parameters also.
== Description of Files in This Feature
The EPTF Core Library ExecCtrl API includes the following files:
* `ExecCtrl` and `ExecCtrlClient`:
** _EPTF_CLL_ExecCtrl_Definitions.ttcn_: This TTCN-3 module contains common type definitions that should be used in `ExecCtrl` and `ExecCtrlClient` components.
** _EPTF_CLL_ExecCtrl_Functions.ttcn_: This TTCN-3 module contains the implementation of Execution Control functions.
** _EPTF_CLL_ExecCtrlUIHandler_Definitions.ttcn_: This TTCN-3 module contains common type definitions that should be used in `ExecCtrl_UIHandler` components.
** _EPTF_CLL_ExecCtrlUIHandler_Functions.ttcn_: This TTCN-3 module contains the implementation of Execution Control UI handler functions.
** _EPTF_CLL_ExecCtrlTimeProfile_Definitions.ttcn_: Types needed for `TimeProfile` functionality
** _EPTF_CLL_ExecCtrl_LoggingFunctions.ttcn_: Functions used for logging in `ExecCtrl`
** _EPTF_CLL_ExecCtrl_PhaseDefinitions.ttcn_: Type definitions for phases
** _EPTF_CLL_ExecCtrl_PhaseFunctions.ttcn_: Function definitions for using phases
** _EPTF_CLL_ExecCtrl_ScenarioDefinitions.ttcn_: Type definitions for scenario, traffic case and entity group databases
** _EPTF_CLL_ExecCtrl_ScenarioFunctions.ttcn_: Scenario database handling functions
** _EPTF_CLL_ExecCtrlClient_Functions.ttcn_: Functions that used by `ExecCtrlClient`
== Description of Required Features from TCC
The `ExecCtrl` feature is part of the TitanSim EPTF Core Load Library (CLL). It relies on several features of the CLL and also some protocol modules and test ports. To use the `ExecCtrl`, the user has to obtain the respective files from the following features:
Features from CLL:
* `Base`
* `Common`
* `LGenBase`
* `Variable`
* `HashMap`
* `UIHandler`
* `Logging`
* `RandomNArray`
* `LoadRegulator`
* `Scheduler`
* `RedBlackTree`
* `FreeBusyQueue`
* `Semaphore`
* `StatHandler`
* `StatMeasure`
Protocol modules:
* XSDNASN protocol module
* XTDP protocol module
TCC Useful library:
* `DateTime`, `Encoding`, `FileIO`, `Maths`, `Conversion` from `TCCUsefulFunctions`
Test ports:
* XTDP test port
* `AbstractSocket` test port
* Telnet test port
* UDP test port
* Socket API
== Installation
Since `EPTF_CLL_ExecCtrl` is used as a part of the TTCN-3 test environment, this requires TTCN-3 Test Executor to be installed before any operation of these functions. For more details on the installation of TTCN-3 Test Executor see the relevant section of ‎[2].
If not otherwise stated in the respective sections, the following are needed to use `EPTF_CLL_ExecCtrl`:
* Copy the files of the features listed in section ‎2.3 to the directory of the test suite or create symbolic links to them.
* Import the `ExecCtrl` demo or write your own application using `ExecCtrl` and `ExecCtrlClient`.
* Create _Makefile_ or modify the existing one. For more details see Execution Control.
* Edit the config file according to your needs, see <<configuration, Configuration>>.
[[configuration]]
== Configuration
The executable test program behavior is determined via the run-time configuration file. This is a simple text file, which contains various sections. The usual suffix of configuration files is _.cfg_. For further information on the configuration file see ‎[2].
The `ExecCtrl` and `ExecCtrlClient` feature in general relies on TTCN-3 module parameters defined for entity groups, traffic scenarios, traffic case types in `LGenBase` ‎in the <<warning-messages, Warning Messages>> section. `ExecCtrl` centralizes and pre-processes the handling of such traffic descriptor parameters and makes the configuration and control easier in complex load generator scenarios. Actual values of these parameters – when no default value or a different from the default actual value is to be used – shall be given in the `[MODULE_PARAMETERS]` section of the configuration file.
Configuration of `ExecCtrl` is possible with the help of the `loadConfig` API function as well. Parameters loaded by this function are appended to existing data. Confiuration data can be loaded by the `loadConfig` function before `ExecCtrl` was started. Since the start function is called automatically in the `ExecCtrl` init function if not disabled, calling of start function should be disabled in the init function to be able to load configuration after the init function is called.
Configuration data from `ExecCtrl` clients can be loaded before the client reports `readyToStart` to `ExecCtrl`. To be able to load configuration from the `ExecCtrlClients`, reporting ready to start in the init function has to be disabled. Additionally, the `ExecCtrl` client has to be created `manually', because `LGens` belonging to `LGen` pools are created after the configuration data was loaded into `ExecCtrl`.
Configuration data is loaded from the module parameters automatically. This can be disabled in the `ExecCtrl` init function.
The module parameters used by the `ExecCtrl` feature are described in the following sections.
=== Control Parameters
These parameters control the behavior of the `ExecCtrl`.
* `tsp_ExecCtrl_ignoreOutOfResource`
+
This boolean type module parameter is defined in module `EPTF_CLL_ExecCtrl_Definitions`. It is used to define the behavior of entity group creation method. When the number of entities to be created in a group exceeds the maximum number of possible entities declared by the Load Generator, and this flag is set to false, the test system stops with configuration error. Default value is: `_true_`.
* `tsp_ExecCtrl_manualControl`
+
This boolean type module parameter is defined in module `EPTF_CLL_ExecCtrl_Definitions`. It is used to define the behavior of the `ExecCtrl` state machine. When this flag is set to true, the configured scenarios will be started only upon user interaction, via Runtime GUI or CLI. Default value is: `_false_`.
* `tsp_EPTF_ExecCtrl_StartStopScenarioDisable`
+
This parameter can be used to specify which Scenario Start/Stop checkboxes should be enabled/disabled at startup. If not specified the Scenario Start/Stop checkboxes are enabled by default, which means they can be started/stopped using the GUI during runtime.
* `tsp_ExecCtrl_LGenBaseStatsUI_columnDescriptorList`
+
This module parameter can be used to enable/disable elements on the `ExecCtrl`/`Clients` tab. See `LGenBase` documentation for details. Default setting is to display all available information with read-only format.
* `tsp_ExecCtrl_LGenBaseStatsUI_scColumnDescriptorList`
+
This module parameter can be used to enable/disable elements on the `ExecCtrl`/`Clients` tab. See `LGenBase` documentation for details. Default setting is to display all available information with read-only format.
* `tsp_EPTF_ExecCtrl_finalTestReportFile`
+
This module parameter specifies the name of the file where the final test report is written. It can also be used to disable final test report generation by setting it to empty string. If enabled (file name specified), the final test report generator functions that were registered in `ExecCtrl` and the `ExecCtrlClients` are called, and the report is written (or appended) to the specified file. The file name can also be a format string where the time-stamp can be defined. For allowed formats see the `f_getTimeFormatted` function description in `TCCDateTime_Functions`. The default value of this module parameter uses this kind of format. Default value: `EPTF_ExecCtrl_FinalTestReport_%Y-%m-%d_%H.%M.%S.txt`.
=== Scenarios and Entity Groups
Some of these parameters are defined in `LGenBase`, but also used by `ExecCtrl`.
* `tsp_LGenBase_EntityGrpDeclarators`
+
This module parameter is defined in `LGenBase`. It is used to declare a list of entity groups. The referred entity types should be already declared by application libraries or from user code using `f_EPTF_LGenBase_declareEntityType()` in the `ExecCtrl` client.
* `tsp_LGenBase_TcMgmt_tcTypeDeclarators2`
+
This module parameter is defined in `LGenBase`. It is used to define a list of traffic case types. The traffic case names should be unique. The referred FSM names should be already declared by application libraries or from user code using, for example, `f_EPTF_LGenBase_declareFSMTable ()` in the `ExecCtrl` client.
+
Makes the `tsp_LGenBase_tcTypeDeclarators` obsolete.
* `tsp_LGenBase_TcMgmt_ScenarioDeclarators3`
+
This module parameter is defined in `LGenBase`. It is used to declare a list of traffic scenarios of type `EPTF_LGenBase_ScenarioTypeDeclaratorList`. The referred traffic case type names should be consistent with traffic case declarations. Empty scenarios (scenario with zero or of traffic cases) are not allowed. This module parameter makes the following scenario declarators obsolete:
+
--
** `tsp_LGenBase_TcMgmt_ScenarioDeclarators`
** `tsp_LGenBase_TcMgmt_ScenarioDeclarators2`
** `tsp_LGenBase_TcMgmt_WeightedScenarioDeclarators`
--
* `tsp_EPTF_ExecCtrl_Scenario2EntityGroupList`
+
This module parameter is used to define a list of entity group – traffic scenario associations. The referred entity group and scenario names should be declared also in `tsp_LGenBase_EntityGrpDeclarators` and `tsp_LGenBase_TcMgmt_ScenarioDeclarators3` (or in other scenario declarators). A scenario instance name can also be associated to the scenario deployed on the given entity group. In addition to the given instance name, the following instance name is automatically associated to the scenario instance: `<EntityGroupName>+ "." + <ScenarioName>`.
+
NOTE: The entity type of the entity group, and the entity type of the traffic cases in the scenario has to be the same. This is checked at startup, and an error is generated if the entity types do not match.
+
This module parameter makes the following declarator obsolete:
+
--
** `tsp_LGenBase_Scenarios2Grps`
--
+
It is allowed to associate more than one scenario to a single entity group. This means that these scenarios can be executed in parallel on the same entity group.
+
Also it is allowed to assign the same scenario to different entity groups. This means that the same scenario can be executed on different entity groups assuming they support the entity type of the traffic cases in the scenario.
* `tsp_EPTF_ExecCtrl_EntityGroupDistributionDeclarators`
+
Using this module parameter custom entity group distribution can be specified. The name of the entity group identifies the entity group for which the distribution is given. The distribution is a list of `LGen` names and weight pairs. The `LGen` name should match with the name of an `LGen` returned by the `f_EPTF_Base_selfName` function. Two distribution for the same entity group is not allowed.
=== Phases
* `tsp_EPTF_ExecCtrl_PhaseList_Declarators`
+
This module parameter is used to define phase lists. Default value: empty list, that is, no phase lists are declared.
* `tsp_EPTF_ExecCtrl_ScenarioGroup_Declarators`
+
This module parameter can be used to define scenario groups. Scenario groups are used for synchronized phase handling. Each scenario in a scenario group should support the same phase lists. The scenario names in this modulepar should be one of the scenario instance names defined in the modulepar `tsp_EPTF_ExecCtrl_Scenario2EntityGroupList`. Default value: empty list.
=== Regulator Parameters
* `tsp_EPTF_ExecCtrl_RegulatorNames`
+
This module parameter specifies the names of the regulators that can be used to regulate scenario parameters such us Scenario CPS or Traffic case CPS. The regulators should have `selfNames` chosen from this list.
* `tsp_EPTF_ExecCtrl_RegulatedItems`
+
This parameter defines the assignment between regulators and regulated items. The regulated items can be Scenario CPS that are identified by `EntityGroup` name and Scenario name, and Traffic case CPS, identified by `EntityGroup` name, Scenario name and `TrafficCase` name. If the scenario is in a scenario group with multiple execution phases, then the phase in which the regulation should take place has to be set also. The regulated items belonging to a regulator or the phase in which the regulation should take place can be changed during runtime from the GUI also.
=== Time Profile Parameters
* `tsp_EPTF_ExecCtrl_TimeProfileDescrList`
+
This module parameter defines the list of available `TimeProfile` descriptors. Each time profile descriptor has a name and a list of `time-targetValue` pair. So each `TimeProfile` descriptor is simply a time-series of target values. These time profile descriptors can be used to build complex time profiles.
* `tsp_EPTF_ExecCtrl_TimeProfileList`
+
This module parameter defines the list of `TimeProfiles`. Each time profile is built up from `TimeProfile` descriptors. It is possible to set the start time (with respect to the start of the scenario), period of repetition (time at which the time series will be repeated) and the number of repetition (the number of times the time series is repeated) for each `TimeProfile` descriptor (time series). These time profile descriptors can be assigned to Traffic Case CPS-s and Scenario CPS-es to define time-dependent CPS levels.
* `tsp_EPTF_ExecCtrl_TimeProfile2TcList`
+
This module parameter can be used to assign a time profile to the CPS of a traffic case identified by the `EntityGroup` name, Scenario name and the `TrafficCase` name, or a CPS of a weighted scenario. The traffic case name for weighted scenario is ignored when identifying the scenario.
=== LGen Pool Parameters
* `tsp_EPTF_ExecCtrl_LGenPool_Declarators`
+
This module parameter can be used to define the `LGen` pools. `LGen` pools are collections of load generators on specific hosts created by user written creator functions.
* `tsp_EPTF_ExecCtrl_EntityGroup2LGenPool_List`
+
This module parameter is used to assign an `EntityGroup` to an `LGen` pool. An entity group can be assigned to one `LGen` pool only, but several entity groups can be assigned to the same `LGen` pool.
+
If an entity group is assigned to an `LGen` pool, all scenario instances belonging to the entity group will be executed on the `LGens` of the `LGen` pool.
+
If an entity group is not assigned to any `LGen` pools, it will be deployed on the default pool. The default pool is the collection of `LGens` that are created by the user. The number of `LGens` in the default pool should be specified in the init function of `ExecCtrl`.
[[parameter_ranges]]
=== Parameter Ranges
Parameter ranges are "chained counters" used to iterate through several integer ranges in a hierarchical way. An integer range defines finite number of increasing consecutive integer values with a start value (`baseOffset`) and count (count). Ranges are used for iterate through its element. The iterator (the actual value of the range) can be used directly or for referencing or indexing other list types inside a traffic generator application. A list of range items defines a chained range. A traffic case in a scenario can have zero or more parameter ranges chained together. The next element of a chained range is calculated by invoking `f_EPTF_Common_incParamRanges()`. When a chained range increased, always the least significant range iterator is increased with one. When all the values used out ("overflow") it increases the next range iterator recursively, etc. The function returns with true, when the most significant iterator (the 0th element inside the range list) finished. When `nrOfRangeLoop` was set for this traffic case type in its declarator, a traffic case finish condition check is also performed.
Parameter ranges may be decomposed into several Load Generators in order to create discrete, non overlapping sub-ranges of the original range by setting the flag `enableSplit` to `_true_`.
Example: Scenario "scenario_0" has 3 ranges handled as one chained range. The 0^th^ element will be decomposed by `ExecCtrl` during initialization `(enableSplit := true)`.
[source]
----
tsp_LGenBase_ScenarioDeclarators := {
{
name := "scenario_0",
tcList := {
{
tcName := "TC0",
startDelay := 0.0,
cpsToReach := 1.0,
enableEntities := true,
enable := true,
ranges := {
{name := "myRange_MSB",
enableSplit := true,
baseOffset := 10,
count := 30},
{name := "myRange_middle",
enableSplit := false,
baseOffset := 10,
count := 30},
{name := "myRange_LSB",
enableSplit := false,
baseOffset := 0,
count := 9}
}
//…
----
=== Parameter Decomposition
The following traffic scenario parameters are decomposed during the initialization:
* `cpsToReach`: always decomposed. The total traffic case cps values are split among load generators running the corresponding scenario. The amount of CPS distributed proportional to the entity number distribution
* `cpsToReach`: always decomposed. The total weighted scenario cps values are split among load generators running the corresponding scenario. The amount of CPS distributed proportional to the entity number distribution
* `ranges`: decomposition can be disabled. Creates discrete sub-ranges of the original one. For more info see <<parameter_ranges, Parameter Ranges>>.
* group finish conditions are not decomposed. All conditions except `nrOfExecStart`, `nrOfSuccesses`, `nrOfFails`, `nrOfTimeouts`, `nrOfErrors` are distributed without splitting (for example,`execTime`). They are evaluated locally on the clients. However, the exceptional ones listed above are not distributed. They are evaluated globally in `ExecCtrl` by summing the appropriate values in the clients.
=== Obsolete Parameters
The module parameters listed in this section are obsolete. They are kept for backward compatibility.
* `tsp_LGenBase_TcMgmt_ScenarioDeclarators`
+
This module parameter is defined in module `EPTF_CLL_LGenBase_Definitions`. It is used to declare a list of traffic scenarios. The referred traffic case type names should be consistent with traffic case declarations. Empty scenarios (scenario with zero or of traffic cases) are not allowed.
* `tsp_LGenBase_TcMgmt_ScenarioDeclarators2`
+
A newer version of `tsp_LGenBase_TcMgmt_ScenarioDeclarators`.
* `tsp_LGenBase_TcMgmt_WeightedScenarioDeclarators`
+
A scenario declarator with CPS. In this scenario the traffic cases have weights which determine how the scenario CPS is distributed among its traffic cases.
* `tsp_LGenBase_tcTypeDeclarators`
+
The old version of the `tsp_LGenBase_tcTypeDeclarators2`. This module parameter can only be used with scenarios defined in `tsp_LGenBase_TcMgmt_ScenarioDeclarators`.
NOTE: `tsp_LGenBase_TcMgmt_tcTypeDeclarators2` can be used with the scenario declarators `tsp_LGenBase_TcMgmt_ScenarioDeclarators2`, `tsp_LGenBase_TcMgmt_WeightedScenarioDeclarators` and `tsp_LGenBase_TcMgmt_ScenarioDeclarators3`. They replace the pair `tsp_LGenBase_TcMgmt_ScenarioDeclarators` and `tsp_LGenBase_TcMgmt_tcTypeDeclarators`. This latter pair of parameters is kept for compatibility. These parameter pairs can be used at the same time also.
* `tsp_LGenBase_Scenarios2Grps`
+
This module parameter is defined in module `EPTF_CLL_LGenBase_Definitions`. It is used to define a list of entity group – traffic scenario associations. The referred entity group and scenario names should be also declared in `tsp_LGenBase_EntityGrpDeclarators` and one of the scenario declarators.
=== Traffic Case Custom Parameters
Traffic case custom parameters provide the possibility to assign arbitrary traffic case type specific parameters inside the common traffic case type descriptors. Since the parameter names and even the values are represented only with charstrings, it is the responsibility of the application libraries to provide function references to convert the parameters to the desired data types during the traffic case initialization. The corresponding functions should be declared prior the test case initializations by `f_EPTF_LGenBase_declareFunction()`.
Example: "TC0" has 2 custom parameters, expecting here 2 different registered functions for the parameters, since they used in different application libraries.
[source]
----
tsp_LGenBase_tcTypeDeclarators := {
{
name := "TC0",
//…
params := {
{aName := "applib_A_paramInterpreter", pName := "header", pValue := "$EXTPATH/sip_support/templates/deregister.header"},
{aName := "applib_B_paramInterpreter", pName := "boost", pValue := "true"}
}
//…
----
Since this type of custom parameters makes the configuration too confusing it is adviced to avoid using them. An alternative way to define custom parameters is to use custom module parameters. Inside this custom module parameter place the identification information of the traffic case to which the custom parameter should belong. For example, for a traffic case instance this identification information is the triplet of the entity group name, scenario name and traffic case name. For a traffic case type, it is the name of the traffic case type. Of course custom parameters can be defined not only for traffic cases but anything identifiable you like. The straightforward advantage of custom module parameters over the traffic case custom parameters is that custom module parameters can be structured and not only charstring type values are allowed.
So the example above can be rewritten like this using custom module parameters:
[source]
----
tsp_Applib_A_paramInterpreter_customParam := {
tcInstanceId := {
eGrpName := "egrp",
scName := "sc",
tcName := "TC0"
},
header :=
"$EXTPATH/sip_support/templates/deregister.header"
}
tsp_Applib_B_paramInterpreter_customParam := {
tcTypeId := "TC0",
boost := true
}
----
=== Customizable GUI
The `ExecCtrl` GUI layout can be customized. This can be done without using the Execution Control UI Handler. The custom GUI layout can be created by loading and appropriate XML into the `UIHandler` feature. This XML should contain `dataSources` for `ExecCtrl`. The `dataSource` name of the `ExecCtrl` is defined by the constant `c_ExecCtrl_DataSource_sourceId`. The required data elements and iterators are created by `ExecCtrl` if the `dataSource` component is passed to the init function of `ExecCtrl`.
These data elements and iterators have certain parameters. The value of these parameters usually come from the iterators. The description of the data elements, iterators and their parameters can be found in the HTML API doc.
= Execution Control UI Handler
The Execution Control UI Handler (`ExecCtrl_UIHandler`) is an extension of the Execution Control in order to display/edit important Execution Control specific information on the GUI. It also creates the Start/Stop/Snapshot/Exit buttons and the status text lines.
To use the Execution Control UI Handler the component should extend the `ExecCtrl_UIHandler_CT` component instead of the `ExecCtrl_CT`. Its init function needs two additional parameters: the component reference to the `UIHandler` and the widget ID where the Execution Control tab will be placed. The `f_EPTF_ExecCtrl_UIHandler_behavior` function starts the execution of the Execution Control UI handler. It calls the behavior function of the Execution Control `f_EPTF_ExecCtrl_behavior` at the end. These behavior functions are just examples and need to be modified by the user of `ExecCtrl` `UIHandler` feature.
Most of the `ExecCtrl` functionality is displayed on the GUI created by the `ExecCtrl_UIHandler` under the `ExecCtrl` tab. To access this GUI from the CLI, the EPTF Variable names associated to the widgets on the GUI shall be used. These names are listed in the Function Description document of `ExecCtrl` ‎in the Usage chapter.
The module parameters used by `ExecCtrl` `UIHandler` are listed in the following section.
== Configuration
* `tsp_EPTF_ExecCtrl_StartStopTCDisable`
+
This module parameter can be used to enable/disable the *StartTC/StopTC* checkboxes on the traffic cases panel.
* `tsp_EPTF_ExecCtrl_UIHandler_disableAutoEnablingOfManualControlModeWhenStopButtonIsPressed`
+
This module parameter can be used to disable the enabling of the manual control mode when the stop button is pressed.
* `tsp_EPTF_ExecCtrl_UIHandler_generateReport`
+
This module parameter enables/disables the built-in final test report generation in the `ExecCtrl UIHandler`. If it is enabled, `ExecCtrl UIHandler` will write its traffic case statistics report into the final test report file.
+
Default value: `_false_`
* `tsp_EPTF_ExecCtrl_UIHandler_noCPSChart`
+
This module parameter can be used to disable the CPS Chart displayed on the `ExecCtrl` statistics panel.
+
Default setting: `_false_` (i.e. the chart is enabled)
* `tsp_EPTF_ExecCtrl_UIHandler_noDensityChart`
+
This module parameter can be used to disable the Density Chart displayed on the `ExecCtrl` statistics panel for density type FSM statistics.
+
Default setting: `_false_` (that is, the chart is enabled)
* `tsp_EPTF_ExecCtrl_UIHandler_CPSChart_maxPointsCurrent`
+
This module parameter can be used to set the maximal points displayed on the CPS Chart for the traffic cases for the current CPS graph.
+
Default: `_2048_`
* `tsp_EPTF_ExecCtrl_UIHandler_CPSChart_maxPointsTarget`
+
This module parameter can be used to set the maximal points displayed on the CPS Chart for the traffic cases for the target CPS graph.
+
Default: `_2048_`
* `tsp_ExecCtrl_UIHandler_densityChartOrientation`
+
This module parameter can be used to set the orientation of the Density Chart on the *FSM Stats* tab on the *Statistics* panel. The default orientation is vertical. Possible values are defined by the type `XULOrientation`.
* `tsp_ExecCtrl_UIHandler_densityChartLabelType`
+
This module parameter defines the label type used for the density Chart bars on the *FSM Stats* tab on the *Statistics* panel. Default value is percentage. Possible values are defined by the type `DistributionchartLabeltype`.
=== Refresh Rates
To be able to define different refresh rates for different `ExecCtrl` GUI elements, the following configuration parameters are provided. The type of all parameters are integers. If zero value is given, the default refresh period will be used, i.e. the `syncInterval` defined in EPTF Variable. For positive values, the refresh period will be set to the `minSyncInterval` time defined in EPTF Variable multiplied by the number given for the module parameter.
* `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_ScGrpStatus`
+
This parameter defines the refresh rate of the `ScenarioGroup` status LEDs.
* `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_CPSChart`
+
This parameter defines the refresh rate of the CPS Chart on the Traffic case data panel.
* `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_TCStats`
+
This parameter defines the refresh rate of the Traffic case Entity statistics on the Traffic case data panel.
* `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_TimeElapsed`
+
This parameter defines the refresh rate of the elapsed time on the status line.
* `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_EntityResourcesTab`
+
This parameter defines the refresh rate of the Entity resource data on the Client Resources panel.
* `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_targetCPS`
+
This parameter defines the refresh rate of the target CPS values.
* `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_currentCPS`
+
This parameter defines the refresh rate of the current CPS values.
* `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_regulatedItem`
+
This parameter defines the refresh rate of the regulated item data on the Regulator panel.
* `tsp_EPTF_ExecCtrlClient_UIHandler_refreshRate_FSMStats`
+
This parameter defines the refresh rate of the FSM statistics on the Traffic case data panel. This parameter belongs to the `ExecCtrlClient_UIHandler`.
=== Setting Custom Refresh Rates for the GUI Elements
Using the module parameters or API functions it is possible to set custom refresh rates for values displayed on GUI by categories. It can be useful when these parameters are not relevant for the user but they generate high CPU load on the `UIHandler` component.
The most of the load is caused by the Traffic case statistics and the FSM statistics (if there are any). To decrease the load, first the refresh rates for these elements should be decreased by increasing the value of the `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_TCStats` and `tsp_EPTF_ExecCtrlClient_UIHandler_refreshRate_FSMStats` module parameters. These will increase the refresh period for traffic case statistics and FSM statistics.
To achieve more responsibility, for example, on the target CPS values the `tsp_EPTF_ExecCtrl_UIHandler_refreshRate_targetCPS` should be decreased.
Please note that decreasing these parameter values not always shortens the refresh period on the GUI. This is the case when the source variable is calculated in a longer refresh period, for example, for the traffic case statistics the source statistics is calculated by the `LGenBase` with the default refresh period.
== Using the GUI
The Execution Control GUI is created by the `ExecCtrl_UIHandler` component. It is a *tabpanel*, which is placed to a *tabbox* widget id specified in the `pl_EPTF_GUI_Main_Tabbox_WidgetId` argument of its init function `f_EPTF_ExecCtrl_UIHandler_init_CT`.
The `ExecCtrl` GUI is shown on the picture below:
See The `ExecCtrl` GUI in the figure below:
image::images/The_ExecCtrl_GUI.png[alt]
There are the following tabs under the *Execution Control* tabpanel: *Statistics*, *Entity Groups*, *Client Resources*, *Traffic Cases*, *Phase Lists*, *Regulator* and *Clients*. These tabs are described in detail in the coming sections.
=== *Statistics* Tab
The statistics panel shows the parameters, control buttons and statistics data of entity groups, scenarios and traffic cases. Picture below shows the *Statistics Panel*.
image::images/The_statistics_tab.png[alt]
The description of the items on the GUI:
1. Select *entity group*, *scenario* and *traffic case*
2. *Entity group* and *scenario info*
3. *Traffic case* parameters and statistics
4. *Scenario* and *traffic case control* buttons
5. *Single shot* parameters and *start* button
6. Main control buttons
7. Group finish condition status LEDs and the condition criteria
8. Scenario, traffic case and group finish status LEDs
9. Runtime GUI status line
10. `ExecCtrl` StatusLEDs
The *traffic case* can be selected by choosing the appropriate *entity group*, *scenario* and *traffic case* from the lists at (1). To increase the display area, the arrows on the top-right corner of the lists can be used to open and close the lists.
Basic information of the selected *entity group*, *scenario* and *traffic case* is displayed at (2). For entity groups the name of the entity group, the entity type, the number of entities in the group, the number of active entities in the entity group, the offset of the first entity in the group, the number of `LGens` the entity group is deployed on and the `LGenPool` the `LGen` is placed are displayed. If there is no `LGen` the entity group could be deployed on, the `Number of LGens deployed on` counter will show zero.
For scenarios the *scenario* instance name is displayed. This name, if had not been specified in the configuration file, is automatically generated from the entity group name and the scenario declarator name. The `PhaseLists` item shows the supported phase list.
An overview of the status of the traffic cases are displayed in the format of status LEDs on the *Traffic case states in scenario*.
See Traffic case states in scenario detail below:
image::images/Traffic_case_states_in_scenario_detail.png[alt]
On the *Traffic Case data* tab the following traffic case parameters are displayed (in case of non-weighted scenario) at (3):
* Target CPS, which is the CPS set by the user (or by the regulator)
* Regulator that regulates the CPS (this item is only shown when regulators are used) If the scenario is in a scenario group with multiple execution phases, the regulator value displayed corresponds to the current phase. Changing the regulator value will change the regulator assigned to the current phase.
See Traffic case entity information in detail below:
image::images/Traffic_case_entity_information_in_detail.png[alt]
For each traffic case a couple of tabs provided to display useful information. The *Entity Stats* tab shows aggregated `LGenBase` statistics and group finish condition information in the form of status LEDs. On the *FSM Stats* tab the TC scope statistics declared in the FSM tables are automatically collected, if available. The *CPS chart* tab shows the current CPS and the target CPS of the traffic case (or scenario) graphically. The *Custom stats* tab is provided to place custom parameters to the GUI by the user. This tab is empty by default and has the widget id
[source]
----
c_EPTF_ExecCtrl_statisticsRoot&".EG."&vl_eGrpName&".SC."&vl_scTypeName&".TC."&vl_tcName&".TrafficCaseStats.CustomStats.tab"
----
==== *Entity Statistics*
The *Entity stats* tab shows the following statistics:
* *Current CPS*, which is the actual CPS generated by the `LGens`
* *Running*: this is the number of entities currently in running state
* *Available*: the available entities
* *Max.Busy*: the maximum of busy entities
* *Fin.Traffic*: the number of entities that finished the traffic
* *Max.Running*: maximum of running entities
* *Min.Available*: mimimum of available entities
* *Not Finished*: number of entities not finished
* *RangeLoops*: number of times the whole range of entities were used
* *ExecTime*: the execution time of the traffic case
* *Starts*: number of times the entities were started
* *Success*: number of times the entities reported success
* *Fail*: number of times the entities reported fail
* *Timeout*: number of times the entities reported timeout
* *Error*: number of times the entities reported error
* *GoS*: Grade of service. This gives `Success/(Success+Fail+Timeout+Error)` in percent.
For more details on these statistics see `LGenBase` documentation.
These values are sampled periodically. The period is the same as the synchronization period in the EPTF Variable feature. The LEDs next to the values display the group finish condtition state. The color blue means that the condition is not fulfilled whereas the red color indicates that the condition has fired. The numbers next to the LEDs show the value of the condition threshold. If a LED is black and there is no text, it means that the corresponding condition was not set for this traffic case.
The (4) are the control buttons of the scenario and the traffic cases in the scenario. They can be used to start/stop/reset the scenario or start/stop the traffic cases in the scenario.
Single shot traffic can be initiated by the *Single Shot* button at (5). This will start the traffic case on the specified entity in the entity group. The logging of the single shot traffic can be enabled by the *Enable Log* checkbox. The entity can be selected by specifying the *Entity index*. It has to fall into the entity group (from `_0_` to groupsize `_-1_`), or `_-1_` is accepted for automatic entity selection. Single shot traffic can be initiated at any stage of traffic case execution.
The main control buttons can be found at the bottom of the panel at (6). These buttons can be used to start all enabled scenarios, stop all running scenarios, terminate all test case execution, generate snapshot, or exit from the application.
The group finish condition status information is displayed by the LEDs at (7). The LEDs are blue if the condition is set for the given item, and next to the LED the criteria is written. The LED color changes to red if the condition is fired. If the LED is black and the text shows "—", it means that the given condition is not monitored. Black LED with text "NA" on anywhere on the `ExecCtrl` GUI means that the value is not available.
The current status of the Scenario, the traffic cases in the scenario, the selected traffic case and the group finish condition overall status is displayed at (8). The group finish status LED color follows the colors of LEDs at (7), but the text shows the condition that fired last. The traffic case and scenario status LEDs are the aggregated value of traffic case and scenario statuses in the `LGens`. If the status is different on the `LGens` (out-of-sync), the LED shows "Mixed" in color yellow. If the LED is Black and shows "Off", that means that there is no `LGens` suitable for executing the scenario and the traffic cases. It can be a mis-configuration, or the `LGens` exited by some reason.
At number (9) some basic status information is shown. One of them is the time elapsed since the test was started. This is the time elapsed in seconds since the execution was started if manual mode false, or since the *Start Test* button was pressed. This time is used by the time profiles also to determine the time-dependent CPS levels. At the bottom line the name of the last updated widget is shown.
At number (10) the status information of the `ExecCtrl` component is shown. The status is displayed in LED format for the `EndOfConfig`, `ReadyToRun`, `GUIDone`, `EndOfTest` events. If a certain event was not detected yet, the corresponding LED color is blue. When the event happens the LED color turns green and stays so from that on.
==== *FSM Statistics*
The *FSM stats* tab shows the aggregated value of traffic case level FSM statistics. These statistics are declared in FSMs on the `LGens` and `ExecCtrl` automatically collects and aggregates them and shows their value on this tab. The values are displayed as a `{statName,statValue}` pair. If the density chart display is not disabled by `tsp_EPTF_ExecCtrl_UIHandler_noDensityChart`, the density statistics are displayed graphically on a distribution chart, otherwise it is displayed as an integer list.
The picture below shows an example FSM stats panel (the actual items displayed on this tab can vary depending on the FSM definition):
image::images/FSM_statistics_for_a_traffic_case.png[alt]
If no FSM statistics is available, a gray text is displayed instead, stating that there is no available data to display.
The density chart on this tab displays how many elements of the measured data falls into a given interval. The various value intervals are displayed on the horizontal axis, while the number of data inside the intervals is displayed as a vertical column.
Zooming in and out is possible by selecting or inverse selecting a rectangle area on the chart while pressing and holding down the left mouse button.
By right-clicking on the density chart a pop-up menu comes up through which the chart can be saved into a _PNG_ image file, or several chart properties can be changed. These properties are lost when the GUI is restarted.
==== *CPS Chart*
For each traffic case a *CPS chart* is provided. This chart shows the target CPS and the current CPS of the traffic case. In case of weighted scenarios the `targetCPS` value shows the `targetCPS` value of the scenario.
The CPS chart is shown on the picture below:
image::images/CPS_chart_for_a_traffic_case.png[alt]
To zoom in the chart select the rectangle to zoom to by the mouse while holding down the left mouse button. To restore original zoom level press the *CPS Chart* button above the chart.
The chart can be saved into a PNG image the by right clicking on the chart and selecting *Save as image ..* from the menu.
This chart is not displayed if the `tsp_EPTF_ExecCtrl_UIHandler_noCPSChart` module parameter is set to `_true_`.
==== Weighted Scenario Data
Some additional information is displayed on the *Statistics* panel if the scenario is weighted or of the scenario belongs to a scenario group.
It is possible to add user defined custom statistics to the traffic case information panel. These will be displayed under the Custom charts tab. The `widgetId` to use:
[source]
c_EPTF_ExecCtrl_statisticsRoot&".EG."&vl_eGrpName&".SC."&vl_scTypeName&".TC.''&vl_tcName&".userSpecificTcData"
See *Statistics* tab for weighted scenarios and/or for scenarios in scenario groups below:
image::images/Statistics_tab_for_weighted_scenarios_and_or_for_scenarios_in_scenario_groups.png[alt]
1. Weighted scenario parameters (only displayed if scenario is weighted)
2. Scenario group information (only displayed if scenario is in a scenario group)
3. Traffic case weight
For weighted scenarios the Current CPS, Target CPS and the regulator is shown that regulates the CPS at (1).
NOTE: At the traffic case parameters (3) the traffic case weight is displayed instead of the Target CPS.
If the scenario is in a scenario group (phase handling) some basic information and control buttons are available at (2). These include the start phase drop down list, the phase selection mode, the scenario group status LED displaying the current phase together with its state and the status of the selected scenario in the group. Checkboxes are provided for starting/stopping the current phase in the scenario group, stopping the scenario group execution and resetting the scenario group. Most of these information can be found on the *Phase Lists* tab also. The scenario control buttons are disabled if the scenario is in a scenario group.
NOTE: Stopping the scenario group can be achieved by unchecking the *StartCurrentPhase* checkbox.
If the scenario group is not running (that is, idle) the current phase can be changed by changing the *Start Phase* value. The regulator displayed corresponds to the regulator used in the current phase. Changing the regulator will change the regulation in the current phase only.
*Scenario Group control buttons*
There are three checkboxes that can be used to control the scenario group execution: *StartCurrentPhase*, *TerminateGroup* and *ResetGroup*.
*StartCurrentPhase*:
Pressing this button will start the actual phase in the scenario group. Pressing it again (removing the tick mark) will stop the current phase and if the mode is *AUTOMATIC* it will start the next phase automatically. Example: Current phase is preamble: Pressing *StartCurrentPhase* will stat the preamble phase. If the mode is *AUTOMATIC* sooner or later the `loadgen` phase will be started. Unticking the *StartCurrentPhase* checkbox will stop the `loadgen` phase, and the `postamble` phase will begin. Use the *StartCurrentPhase* checkbox if you would like to stop the current phase and continue with the next phase automatically.
*TerminateGroup*:
This check box can be used to stop the execution of the scenario group entirely. After this, the scenario group can be started by *StartCurrentPhase*, but all data will be reset.
Example: If you press the *TerminateGroup* checkbox in the `loadgen` phase, the scenario group will stop, and the next phase will not be started. After that if the *StartCurrentPhase* checkbox is pressed it will start the scenario group in the loadgen phase (since this is the phase it was stopped in). But because the database is reset after stop, it is possible that no traffic will be generated: Titansim will think that no users are registered. To be able to generate traffic after pressing *TeminateGroup*, the phase should be changed back to preamble.
=== *Entity Groups* Tab
The *Entity Groups* panel shows the overview of the entity groups declared in the system. It presents information on the entity type and the number of entities in the group (that is, the group size). The following picture displays the *Entity Group* tab:
image::images/the_entity_groups_tab.png[alt]
=== *Client Resources* Tab
The *Client Resources* panel shows the resource information of the `LGens`. For every `LGen` the supported entity types, the number of maximal available entities of a given entity type and the currently available number of entities are displayed on the *Resource information* section of this panel. The number zero is displayed if no entities available on the given `LGen`, or if the `LGen` terminated. The number `_-1_` is shown when there is no upper limit on the entity number. If the line is empty for an `LGen`, that means that the `LGen` does not support any entity types.
Under the *Entity group distribution overview* the entity groups are listed according to their `LGen` distribution. For each entity group those `LGens` are listed on which they are distributed. For each distributed part the *eCount* shows its size on the `LGen`, that is, how much entities it contains. The value of *eOffset* gives the global offset of the first entity of the distributed part. If an entity group was not distributed to any `LGens`, the corresponding columns are left empty.
The sum of the *eCount* values for the same entity group gives the size of the entity group (which is displayed on *Entity Groups* panel also); while the first *eOffset* value for an entity group gives the global offset of the entity group itself.
The picture below shows this tab:
image::images/the_client_resources_tab.png[alt]
== *Traffic Cases* Panel
On the *Traffic Cases* panel the scenario and traffic case data is shown. It gives an overview of the distribution of scenarios on `LGens` and an overview of scenario and traffic case parameters. The states of the scenarios are displayed per `LGen` and also the overall scenario state is shown as a status LED. A short text next to the LED gives textual information on the current state. These states correspond to the states defined in `LGenBase`. The accumulated scenario status LEDs, which show the overall state of the scenario on all `LGens`, are updated if the states on all `LGens` are the same. Otherwise the "Mixed" text is displayed and the LED color is set yellow. The following list describes the states not present in `LGenBase`:
* Black – "NA": The value is not available. The `LGen` is not able to execute that scenario, because entities are not available
* Black – "Off": The corresponding `LGen` is terminated; information is not available any more.
* LED is missing: no scenario is assigned to that entity group or the `LGen` does not support any entity groups, i.e. no entity group is deployed on that `LGen`, or no scenario is assigned to that entity group.
* Yellow – "Mixed" : the state is out of sync, the scenario state is different on the `LGens`
The *Traffic Cases* panel is divided into two parts. The *Scenario distribution overview* and the *Traffic case overview*.
The *Scenario distribution overview* presents the scenario distribution information. For each `LGen` the entity groups deployed on them and the scenarios assigned to the entity groups are listed. The `Client status` column shows the status LEDs for the scenario.
The *Traffic case overview* collects the main traffic case parameters and control buttons. It also displays the synchronized scenario status. The *Typ* column informs whether the type of the scenario is normal (`Decl`) or weighted (`Weight`). Next to the status LEDs are placed the *start/stop* checkboxes, which can be used to start and stop the scenario. These checkboxes can be disabled from the configuration file. If the scenario is weighted, the *CPS* column can be used to set the target CPS for the scenario. Then the traffic cases in the scenario are listed below each other. The *StartTC*/*StopTC* checkboxes are provided to start and stop the traffic cases. The *Start delay* column shows the time the start of the traffic case is delayed after the scenario was started. In the *TargetCPS/Weight* column the target CPS of the traffic case (normal scenario) or the traffic case weight (weighted scenario) can be adjusted. The *TimeProfile* and *Regulator* columns show if there is a time profile or a regulator configured to control the CPS value automatically.
The Traffic Cases panel is shown below:
image::images/The_Traffic_Cases_tab.png[alt]
== *Regulator* Panel
This panel shows all CPS values that can be regulated by regulators. These include scenario CPS-es and traffic case CPS-es. The type is shown in the *Item Type* column. Every traffic case CPS value is identified by the entity group name, scenario name and traffic case names separated by '.'. Scenario CPS-es do not contain the traffic case name. This information is shown on the *Item Name* column. The *Regulator Name* shows the name of the regulator that is set to regulate that item. This can be changed during runtime. It is possible to regulate more than one item with the same regulator. In this case the weight of the items determines what portion of the total CPS is used for the given item. Each item can be enabled in the "Enabled" column by checking the checkbox.
The *Regulator* panel is shown below:
image::images/The_Regulator_tab.png[alt]
Below the list of regulated items the data of the regulators are listed. It is possible to adjust the target load here also. The required CPS that is needed to reach that target load is displayed in the *Regulated Value* column. This value is split based on the weights between the regulated items belonging to that regulator. The actual load is displayed in the column *Current Load*. The status of the regulators can be monitored via their status LED. Stable means, that the target load is reached, instable means that the regulator is adjusting the CPS to reach the target load level. Disabled means that all items regulated by the regulator belong to a scenario that is not running. If the regulator is not connected, the text Disconnected is shown. In this case the user is able to adjust the *Regulated Value* manually instead of the *Target Load*.
== *Phase Lists* Panel
The *Phase Lists* panel shows the status and control buttons of execution phases for scenario groups. It is described in more detail in the GUI for *ScenarioGroups* and *PhaseLists* section.
image::images/The_Phase_Lists_tab.png[alt]
= Execution Control Client
The Execution Control Client (`ExecCtrlClient`) is the client side interface towards the Execution Control component. These clients are also referred to as `LGens`, since they should extend the `LGenBase` component, are created, configured and started by the Execution Control component. The clients execute the traffic cases.
Each client shall declare the supported behavior types, entity types, FSMs. The `ExecCtrl` uses this information to deploy the entity groups on the clients, and executes traffic cases on the corresponding `LGens`.
The `ExecCtrlClients` can be organized into `LGenPools` in order execute traffic cases in parallel, which makes the system scaleable.
== Configuration
The following module parameters can be used to configure the `ExecCtrlClient` behavior.
`tsp_EPTF_ExecCtrlClient_terminateIfExecCtrlTerminates`
This boolean type module parameter can be used to enable/disable the termination of the `ExecCtrlClient` component when `ExecCtrl` terminates. If enabled, all `ExecCtrlClient` components are shut down before `ExecCtrl` terminates. Otherwise they are terminated by the Base cleanup mechanism when the system terminates. Default value is: `_true_`.
= Execution Control Client UI Handler
The Execution Control Client UI Handler (`ExecCtrlClient_UIHandler`) is the extension of the `ExecCtrlClient` that adds the functionality of displaying `LGenBase` statistics information on the GUI under the *Clients* tab. It is not possible to change the displayed settings by the user, since they are all controlled by `ExecCtrl`. This is why the items on the *Clients* panel are disabled. The data displayed on this tab for a given scenario is aggregated on the *Statistics* panel for all `LGens` running that scenario.
The *Clients* panel is shown below:
image::images/The_Clients_tab.png[alt]
== Configuration
* `tsp_EPTF_ExecCtrlClient_UIHandler_createClientTab`
+
This module parameter can be used to prevent the `ExecCtrl` clients to create their `Clients` tab on the `ExecCtrl` panel. If it is set to `_false_`, the client statistics is not shown. This can speed up execution and shorten the start-up time. Default setting: `_true_` (that is, the panel creation is enabled)
* `tsp_EPTF_ExecCtrlClient_UIHandler_refreshRate_FSMStats`
+
This parameter defines the refresh rate of the FSM statistics on the Traffic case data panel.
= Usage
The `ExecCtrl` or the `ExecCtrl_UIHandler` component can be a stand-alone component, which means that after creation its behavior function can be started on it. After that all `ExecCtrlClient` components should get the component reference of this component so that they can establish connection towards the `ExecCtrl` or the `ExecCtrl` UI Handler component. There can be only one `ExecCtrl` component in the test configuration. The `ExecCtrlClient` components can be used as an interface to the `LGenBase` feature. Note, that in the `ExecCtrlClient` component the initialization should follow this order:
1. Initialize the `LGenBase`
2. Declare entity types
3. Initialize the `ExecCtrlClient`
4. Declare more entity types
5. Report `readyToStart` towards `ExecCtrl`
== Using `ExecCtrl`
The `ExecCtrl` feature can be used without calling its behavior function. In this case the `ExecCtrl` API can be used to initialize, configure, start and terminate it.
The `ExecCtrl` feature has to be initialized first by its init function. This `init` function loads the module parameters by default and starts the execution of the test cases automatically.
To be able to load additional configuration data, the `loadConfig` function can be used. This function has to be called before the operation of `ExecCtrl` is started. This means that the automatic calling of start function has to be disabled in the `init` function of `ExecCtrl`.
When all configuration data is loaded by the `loadConfig` function, the manual control mode has to be set. The automatic mode means, that when the operation of `ExecCtrl` is started, all enabled scenarios and scenario groups will be started automatically.
After the configuration of `ExecCtrl` is finished, the operation of `ExecCtrl` can be started by the start function. After that the code has to enter into an infinite alt loop. In this alt loop the default altsteps will handle the events and operate `ExecCtrl`. `LGens` belonging to `LGenPool` will be created by the start function, or can be created after the start function is called by the `createLGens` function. If there are `LGens` that should be created manually, they can be created after `ExecCtrl` is started. Regulator components, if they are used, have to be created also after `ExecCtrl` is started.
During execution, scenarios can be started and stopped; CPS can be adjusted, etc.
At the end of the test the exit function has to be called, or the `ExecCtrl` component has to be stopped using the Base feature. A final test report will be generated if configured to do so at exit.
== Events in `ExecCtrl`
The following events can be detected in ExecCtrl and ExecCtrl_UIHandler:
* `EndofConfig` - happens when the all client configuration has finished. This event cannot be checked, and there is no callback function for this event in `ExecCtrl` yet.
* `ReadyToRun` - happens when all clients are reported ready to run. By the time this event happens, all variables had been created, and subscribes had been done for variables in all `ExecCtrlClients`. The state can be checked by `f_EPTF_ExecCtrl_checkReadyToRun`.
* `GuiDone` - happens when ExecCtrl_UIHandler finished creating its GUI and all `ExecCtrl` clients have reported the `GUIDone` event to `ExecCtrl`. This condition can be checked by the function: `f_EPTF_ExecCtrl_UIHandler_checkGuiDone` in `ExecCtrl` `UIHandler`.
* `ScenarioGroupPhaseChange` - happens when the phase of the scenario group changes. Callback functions that are called at this event can be registered by the function `f_EPTF_ExecCtrl_registerScenarioGroupPhaseChangedCallback`
* `ScenarioStateChange` - happens when the state of the scenario on all `LGens` becomes the same (i.e. becomes syncronized). Callback functions that are called at this event can be registered by the function `f_EPTF_ExecCtrl_registerScenarioStateChangedCallback`.
* `TrafficCaseStateChange` - happens when the state of the traffic case on all `LGens` becomes the same (i.e. becomes syncronized). Callback functions that are called at this event can be registered by `f_EPTF_ExecCtrl_registerTrafficCaseStateChangedCallback`.
* `OnGroupFinishCondition` - happens when any of the `onGroupFinish` conditions becomes true, or when all set to false. Callback functions registered by the function `f_EPTF_ExecCtrl_registerOnGroupFinishCallbackFn` are called when this event occurs.
* `CPSChange` - happens when a traffic case or a scenario target CPS changes. Callback functions registered by `f_EPTF_ExecCtrl_registerCPSChangedCallback_TC` for traffic cases and `f_EPTF_ExecCtrl_registerCPSChangedCallback_SC` for scenarios are called when the target CPS for the corresponding traffic case or scenario changes (that is, when the `f_EPTF_ExecCtrl_setCps_TC or f_EPTF_ExecCtrl_setCps_SC` function was called).
* `EndOfTest` - happens when any `LGen` reports the `EndOfTest` event or when the Exit button is pressed. Functions registered by `f_EPTF_ExecCtrl_registerFinalTestReportGeneratorFn` are called.
Events in `ExecCtrlClient`:
* `ReadyToStart`: To report this event to ExecCtrl the function `f_EPTF_ExecCtrlClient_readyToStart` should be called, or it is called automatically in the client’s `init` function if enabled to do so. Call this function only after all entity types are declared. Entity types declared after calling this function will be invisible for `ExecCtrl`.
* `ScenarioInitialized`: When a scenario is created in the `ExecCtrlClient`, the function registered by `f_EPTF_ExecCtrlClient_set_scenarioInitialized_fcb` is called.
* `EndOfConfig`: This event is detected when `ExecCtrl` finished configuring the `ExecCtrlClient` and the `scenarioInitialized` callback function finished its operation. Callback functions registered with `f_EPTF_ExecCtrlClient_registerEndOfConfigCallback` will be called in the order they were registered when this event is detected. The event can be detected by the `f_EPTF_ExecCtrlClient_checkEndOfConfig` function.
* `GuiDone`: This event occurs when the ExecCtrl reports this event to the Client (when the `ExecCtrl` GUI is ready) and all call-back functions registered by `f_EPTF_ExecCtrlClient_registerGuiDoneCallback` have finished in the `ExecCtrlClient`. The event can be detected by the function `f_EPTF_ExecCtrlClient_checkGuiDone`. Also, callback functions can be registered by `f_EPTF_ExecCtrlClient_registerGuiDoneCallback`. The `ExecCtrlClient` (if not disabled in its init function) reports a `GUIDone` event to `ExecCtrl` when these call-back functions all return. The `ExecCtrl` synchronizes this reported `GUIDone` events. It is possible to disable the automatic reply and the `GUIDone` event can be reported to `ExecCtrl` later (for example, after custom GUI has been created) by the `f_EPTF_ExecCtrlClient_reportGUIDone` function.
* `GUIDoneReported`: This event happens when the `ExecCtrlClient` has reported the `GUIDone` event to `ExecCtrl`. This event can be checked by the `f_EPTF_ExecCtrlClient_checkGuiDoneReported` function.
* `EndOfTest`: happens when any `LGen` reports the `EndOfTest` event or when the *Exit* button is pressed. Functions registered by `f_EPTF_ExecCtrlClient_registerFinalTestReportGeneratorFn` are called.
== Using `LGen` Pools
The `LGen` pools can be useful to deploy the `LGen` components automatically by the `ExecCtrl` with the help of user defined `LGen` creator functions.
`LGens` created manually will be placed in the "default pool". The number of manually created `LGens` should be specified in the init function of `ExecCtrl` or `ExecCtrl_UIHandler` (`f_EPTF_ExecCtrl_init_CT`, or `f_EPTF_ExecCtrl_UIHandler_init_CT`).
The `LGen` pool definition consists of a list of triplets containing the creator function, the hostname and the number of `LGens` to create on that host. Since the creator functions are implemented by the user, they have to be registered by the user into `ExecCtrl` so that they can be referred to from the configuration file as a string. This registration can be done by the `f_EPTF_ExecCtrl_loadConfig` function using its `pl_EPTF_ExecCtrl_LGenFunction_Entry_List` parameter. Note, that although it is possible to specify a custom name for the function, the following name can also be used in the `tsp_EPTF_ExecCtrl_LGenPool_Declarators` module parameter even if no custom name is given: `<Modulename.functionName>`.
The creator function should create the `LGen` (the `LGen` should extend the `ExecCtrlClient_CT` component) on the specified host. It is not checked by ExecCtrl that the `LGen` created is actually running on the given host. The function should return null if the `LGen` could not be created, or if the function deploys non-`LGen` components, i.e. components that do not extend `ExecCtrlClient_CT`, or if the creation failed. Otherwise it should return the component reference to the created `LGen`. The `LGen` creator function should run on a component that extends `ExecCtrl_CT` because the creator functions are called by `ExecCtrl`.
The Entity Groups can be associated to `LGen` pools with the help of the `tsp_EPTF_ExecCtrl_EntityGroup2LGenPool_List` module parameter. One Entity Group can be assigned only to one `LGen` pool, while one `LGen` pool can support more than one Entity Groups. The Entity Groups not associated to any `LGen` pool will be declared on the default pool.
When using `LGen` pools, the following should be taken care of:
* The creator functions are registered, otherwise the `LGens` of the pools cannot be created, because the function names in the configuration file are not recognized.
* Assure that there are `LGens` in the `LGen` pool with entity types suitable to support the entity groups associated to the `LGen` pool.
* The `LGens` have enough entities to support the Entity Groups.
* At least one Scenario is added to the Entity Group.
NOTE: The LGen creator functions shall have a runs on clause with a component that extends `ExecCtrl`. Otherwise a compilation error is shown stating a "runs on cause mismatch". If the created `LGens` need the UIHandler component reference (for example for creating their own GUI) the `LGen` creator function shall run on a component that extends `ExecCtrl` and `UIHandlerClient`. The UIHandler component reference can be accessed via the following variable in the `UIHandlerClient`: `v_UIHandlerClient_DefaultUIHandler`.
== Limited Traffic Execution
Limited traffic execution means that the traffic case is executed only on a part of the entire entity group. In this smaller part of the entity group are the active entities which can execute the traffic. The size of the active part of the entity group can be changed during runtime. If the traffic case is in a running state when the number of active entities is changed, all statistics values of the traffic cases will be reset and the CPS values will be redistributed on the `LGens`.
The number of active entities has to be between `_zero_` and the number of allocated entities. If the value is out of this range, the value will be adjusted to the smallest or largest permitted value.
The initial value of the number of active entities is the number of allocated entities. The traffic case is executed with different number of active entities in the same way as if all the entities were active, except that the number of entities that are allowed to execute the traffic is different. This means that traffic finish actions are executed.
= Multiple Execution Phase Support
== Function Specification
Execution Control component supports synchronized execution phases.
TitanSim R1 supported three phases of execution: pre, load generation and post phase. This was removed from the `ExecCtrl` of TitanSim R2. A scheme similar to R1 is implemented in the `ExecCtrl`, but with arbitrary number of named execution phases.
It is possible to configure which scenarios/traffic cases are enabled for which execution phases. The currently selected execution phase can be sent to all `ExecCtrlClients` and set in `LGenBase`.
* The user is able to declare phases that are executed consecutively on a group of Scenarios. (Declaration can appear as function call or in config file)
* Phases are synchronized for a Scenario group.
* The Execution Control GUI provides the means to control (start/stop) the scenario groups and their state information is also displayed.
== Overview
TitanSim R1 supported three phases of execution: pre, load generation and post phase. This was removed from the `ExecCtrl` of TitanSim R2. A scheme similar to R1 is implemented in the `ExecCtrl`, but with arbitrary number of named execution phases. Let’s see an example. There are three main phases: `preamble`, `load generation`, `postamble`. See below figure:
image::images/Phase_example.png[Phase example]
When the preamble phase is started the registration and the re-registration traffic cases are started. In the registration traffic case the entities are enabled by default, in the re-registration they are disabled. When an entity makes a successful registration the same entity is enabled in the re-registration traffic case (therefore there is an arrow in the figure), thus this entity will be kept registered. When the registration traffic case was finished (all the entities tried to register in) the execution is going to the next phase. The load generator reports that the phase was finished successfully to the `ExecCtrl` that synchronizes the phase execution. And the next phase will be launched.
In the load generation phase, the main traffic case is started, this is where the actual call generation takes place (`basiCallOrig TC`). Initially in this traffic case the entities are disabled, but those who managed to register in were made available by the registration traffic case. As the `basicCallOrig` is finished it reports its phase finish and as soon as all the scenarios reported this phase was finished the final phase is started.
In the `postamble` phase the re-registration traffic case is stopped (disabled) and the de-registration traffic case is started. As all the entities are de-registered, the phase is reported as finished.
== Declarations
=== Phase Lists
A named phase list can be declared using the `tsp_EPTF_ExecCtrl_PhaseList_Declarators` module parameter. It consists of the phase definitions and an enable/disable flag:
[source]
----
tsp_EPTF_ExecCtrl_PhaseList_Declarators :=
{
{
name := "GeneralPhaseList",
phases :=
{
{
name := "preamble",
enabled := true
},
{
name := "loadgeneration",
enabled := true
},
{
name := "postamble",
enabled := true
}
}
}
//, …
}
----
[[scenario_groups]]
=== Scenario Groups
A scenario group can be built from scenario instances. These scenario instances will be synchronized inside the group. A declared phase list must be assigned to the scenario group also, the phases of the phase list will be executed on the scenarios. A scenario can be added into the scenario group only if it can handle the given phase list. For each scenario group there is a mode filed, which tells the `ExecCtrl` whether the group should be executed automatically with no human interaction or manually, where the phases must be executed individually by the user.
A named scenario group can be defined using the `tsp_EPTF_ExecCtrl_ScenarioGroup_Declarators` module parameter:
[source]
----
tsp_EPTF_ExecCtrl_ScenarioGroup_Declarators :=
{
{
name := "basicCallGroup",
execMode := AUTOMATIC,
scenarioNames := { "orig", "term" },
phaseListName := “GeneralPhaseList”
}
//, …
}
----
== Databases
There are two main databases
* One for the phase list declarators
* And another for the scenario groups
Both databases are using FBQ (so removing scenario groups and phase lists is possible to do in the future) and hash maps to make the lookups faster.
The phase list declarators are stored as is, but from the scenario group declarators we create scenario group instances. A scenario group instance for the above declarator (<<scenario_groups, Scenario Groups>>) can be seen here.
[source]
----
template EPTF_ExecCtrl_ScenarioGroup_Instance t_myScenarioGroup_Instance_storeSG :=
{
name := “basicCallGroup”,
execMode := AUTOMATIC,
scenarios :=
{
{
name := "orig",
idx := -1,
lgenIndexes := {0,1},
lgenPhaseLists := {t_myPhaseList_Instance_1, t_myPhaseList_Instance_1}
},
{
name := "term",
idx := -1,
lgenIndexes := {0,1},
lgenPhaseLists := {t_myPhaseList_Instance_1, t_myPhaseList_Instance_1}
}
},
scenarioPhaseLists :=
{
t_myPhaseList_Instance_1,
t_myPhaseList_Instance_1
},
groupPhaseList := t_myPhaseList_Instance_1,
phaseFinishAction := null,
groupFinishAction := null,
isRunningVarIdx := -1,
internalAdjust := false
}
template EPTF_ExecCtrl_PhaseList_Instance t_myPhaseList_Instance_1 :=
{
name := “GeneralPhaseList”,
phases :=
{
{
name := "preamble",
enabled := true,
state := IDLE
},
{
name := "loadgeneration",
enabled := true,
state := IDLE
},
{
name := "postamble",
enabled := true,
state := IDLE
}
},
actualPhaseIndex := 0
}
----
For each scenario a phase list instance is stored in the scenarioPhaseList field, where state of the actual phase is stored. For each LGen a scenario is running on there is also a phase list instance in the lgenPhaseLists field. In addition to these there is an overall phase list instance for the whole scenario group, where we keep track of the overall state of the phase execution.
The phases for each scenario can be adjusted individually.
The phase states are the following:
* IDLE
* RUNNING
* SKIPPED
* STOPPING
* FINISHED
== Execution
Only that scenario group can be started, where none of the scenarios are running.
Pseudo code:
[source]
----
. startScenarioGroup(in ScenarioGroupName)
.. for each phase in phase list
... for each scenario
1. for each LGen the scenario is running on
.... send startPhase(name, enabled) request via ExecCtrl i/f to ExecCtrlClient to each LGen
... for each scenario
1. for each LGen the scenario is running on
a. wait for phaseFinished response
..... set the phase state accordingly
... set the main phase state in the main phase list
... go to next phase
----
[[execctrl-execctrlclient-phase-pdus]]
== `ExecCtrl`/`ExecCtrlClient` Phase PDUs
This section describes the PDUs that are sent between the `ExecCtrl` and `ExecCtrl` client.
=== Phase Start Request
Direction: ExecCtrl -> ExecCtrlClient
Purpose: With this request a certain phase can be started on a given Scenario instance on a specific load generator.
Contents:
* `phaseName` - `charstring` - phase to be started
* `scenarioInstanceName` - `charstring` - name of the scenario instance
* `state` - `<EPTF_ExecCtrl_Phase_States>` - the action that must be performed can be either RUNNING or SKIPPING
* `msgID` - `<EPTF_IntegerList>` - `msgID` contains the following indices respectively: scenario group idx, scenario idx, lgen idx, phase idx
=== Phase Stop Request
Direction: ExecCtrl -> ExecCtrlClient
Purpose: With this request a certain phase can be stopped on a given Scenario instance on a specific load generator. After the current phase is stopped, the next phase will start (in AUTOMATIC mode).
Contents:
* `phaseName` - `charstring` - phase to be stopped
* `scenarioInstanceName` - `charstring` - name of the scenario instance
* `state` - `<EPTF_ExecCtrl_Phase_States>` - the action that must be performed can be only STOPPING
* `msgID` - `<EPTF_IntegerList>` - `msgID` contains the following indices respectively: scenario group idx, scenario idx, lgen idx, phase idx
=== Phase Stop Test Request
Direction: ExecCtrl -> ExecCtrlClient
Purpose: With this request a certain phase can be stopped on a given Scenario instance on a specific load generator. After the current phase is stopped, the next phase will not start (even in *AUTOMATIC* mode).
Contents:
* `phaseName` - `charstring` - phase to be stopped
* `scenarioInstanceName` - `charstring` - name of the scenario instance
* `state` - `<EPTF_ExecCtrl_Phase_States>` - the action that must be performed can be only IDLE
* `msgID` - `<EPTF_IntegerList>` - `msgID` contains the following indices respectively: scenario group idx, scenario idx, lgen idx, phase idx
=== Phase Status Response
Direction: ExecCtrlClient -> ExecCtrl
Purpose: With this response the ExecCtrlClient can report the state of a certain scenario in a certain phase.
Contents:
* `phaseName` - `charstring` - phase to be stopped
* `scenarioInstanceName` - `charstring` - name of the scenario instance
* `state` - `<EPTF_ExecCtrl_Phase_States>` - the state of the scenario in given phase.
* `msgID` - `<EPTF_IntegerList>` - `msgID` contains the following indices respectively: scenario group idx, scenario idx, lgen idx, phase idx
== GUI for `ScenarioGroups` and `PhaseLists`
In the Execution Control->Phase Lists tab there separate tab panels for each declared phase list. For an example screen see Figure 2.
image::images/phaselists.png[phaselists]
On the phase lists tab those declared scenario groups can be seen that are using the given phase list.
* *GroupName*: Name of the scenario group
* *GroupPhase*: The desired start phase can be set here. The name of the phase must be typed in correctly. The phase can be modified only if the scenario is on IDLE state.
* *GroupMode*: The mode of the execution can be set here. The name of the mode must be typed in correctly. Available choices: "AUTOMATIC", "automatic", "MANUAL", "manual". The phase can be modified only if the scenario is on IDLE state.
** In *AUTOMATIC* mode the phases will be executed consecutively without human intervention
** In *MANUAL* mode the execution will be stopped after a phase finished. To start the next phase the user has to start the scenario group again.
* *GroupStatus*: This led provides you the actual phase and the actual state of the phase in the scenario group.
* *GroupStart*: By checking in the checkbox in the first row of the scenario group, the whole group can be started. By checking out, the scenario group is stopped.
* *ScenarioName*: Each row contains one scenario member of the group.
* *ScenarioStatus*: This led provides you the actual phase and the actual state of the phase regarding one scenario.
The following check boxes are for setting if a certain phase must be executed or skipped in case of a scenario.
= Error Messages
NOTE: Besides the below described error messages, error messages shown in ‎<<_2, [2]>> or those of other used features or product may also appear.
`*unknown entityType: <entity_type_name>*`
No such entity type.
[[warning-messages]]
= Warning Messages
NOTE: Besides the below described warning messages, warning messages shown in <<_2, [2]>> or those of other used features or product may also appear.
`*outOfResources when creating initial entity group: <group_name> <entity_type_name> <entities_created> <entities_left>*`
Cannot create the full entity group due to insufficient resources, that is, the group may contain less element then originally desired.
= Examples
The "demo" directory of the deliverable contains the following examples:
* _execctrld.cfg_
* __ExecCtrl_Demo.ttcn__
* __AppLib_A_Definitions.ttcn__
* __AppLib_A_Functions.ttcn__
* __ExecCtrlUIHandler_Demo.ttcn__
* __ExecCtrlLGenPool_Demo.ttcn__
* __ExecCtrlLGenPool_Demo.cfg__
== Configuration File
The used configuration file (_execctrld.cfg_) is for the `ExecCtrl` example is placed in the demo directory. You may change Runtime GUI related parameters, like:
[source]
----
EPTF_CLL_UIHandler_Widget_Functions.tsp_xtdp_listen_addr := "127.0.0.1"; // RuntimeGUI is running on localhost
EPTF_CLL_UIHandler_Widget_Functions.tsp_xtdp_listen_port := 55678;
----
The configuration file _ExecCtrlLGenPool_Demo.cfg_ is a simple setup to demonstrate how to configure `ExecCtrl` when `LGen` pools are used.
== Demo Module
The demo module (__ExecCtrl_Demo.ttcn__) illustrates a typical usage of the execution control feature, while __ExecCtrlUIHandler_Demo.ttcn__ demonstrates the usage of the execution control UI handler feature. The module __ExecCtrlLGenPool_Demo.ttcn__ shows how to register the LGen creator function and how to use `LGen` pools. It is also demonstrated how to create a component that is not an `LGen`.
Example Load Generator component definition using feature "A" with `ExecCtrlClient`:
[source]
----
type component ExecCtrl_Demo_CT extends EPTF_LGenBase_CT, EPTF_ExecCtrlClient_CT, LGen_A_CT {
var integer v_myBIdx;
}
----
The initialization of `ExecCtrlClient` feature should called only after all the extended application library initializations (incl. virtual application libraries) in `f_LGen_Demo_init()`:
[source]
----
f_EPTF_ExecCtrlClient_init_CT(pl_selfName, pl_ExecCtrlRef);
----
The main altstep of the feature should put into the main event handler altstep, or, alternatively, activate as default altstep:
[source]
----
alt {
[] t.timeout {}
}
----
MTC should extend and initialize `UIHandler` in order to provide user interface for interactive features (limited functionality in the current drop):
[source]
----
type component myMTC_CT extends EPTF_Base_CT, EPTF_CLL_UIHandler_CT {}
//…
map(self:EPTF_guiPortIf,system:EPTF_guiPortIf);
f_EPTF_CLL_UIHandler_init_CT("ExecCtrlDemo_UIHandler", true, ""/*pl_wndLayout*/);
f_EPTF_CLL_UIHandler_clearGUI();
f_EPTF_CLL_UIHandler_addWindow();
f_ExecCtrl_Demo_initGui();
----
Starting `ExecCtrl` from MTC:
[source]
----
var EPTF_ExecCtrl_CT ExtCtrl := EPTF_ExecCtrl_CT.create;
ExtCtrl.start(f_EPTF_ExecCtrl_behavior("ExecCtrl", tsp_nrOfLGens));
----
= Terminology
*Core 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 Core Library is to be supplied and supported by the TCC organization. Any Core Library development is to be funded centrally by Ericsson.
*ExecCtrl:* +
It is control logic for provisioning and executing test _scenarios_ with TitanSim based load generators.
*ExecCtrl UI Handler:* +
It extends the `ExecCtrl` functionality with user interface.
*Scenario:* +
It is a collection of traffic cases deployed on an _entity group_.
*Entity group:* +
A group of entities with homogenous _entity type_. The indices of the _entities_ of the group make a continuous interval that does not overlap with the indices range of any other entity group.
*Entity type:* +
The type of the entity. It defines what kind of behavior types the entity supports, what kind of functionality the entity is capable of. The entity type of the _entity group_ on which the _scenario_ is deployed, and the entity type of the traffic cases in the scenario, has to be the same.
*LGen:* +
Load Generator: a component providing an implementation for final state machine handling and traffic case management in a load test environment. ExecCtrl manages LGens via its ExecCtrlClient interface.
*Entities:* +
These are "things/objects" that are simulated by the _LGen_. Such "things" are usually the "users", "calls", "servers", "terminations", or anything whose external behavior is to be simulated by the _LGen_. Usually an _LGen_ simulates more than one entity.
*FSM table:* +
This is a formal specification of the communication rules of Finite State Machines. These indexable records are stored in v_LGenBase_fsmTables. FSM tables realizing _traffic cases_ must obey certain rules.
*Traffic case type:* +
This is a prototype used as an input for instantiating traffic case instances on a specific entity group. It defines what _FSM table_ to use, what _entity type_ must be used by the _entity group_ where the _traffic case_ is to be deployed
*Traffic case:* +
This is a behavior"efined by an FSM table, that is executed on a given entity group. All entities of the entity group participate in executing the traffic case. An entity group may have more than one concurrent traffic cases
= Abbreviations
CLL:: Core Library
EPTF:: Ericsson Performance Test Framework
TitanSim:: New synonym for the EPTF Framework
TCC:: Test Competence Centre in ETH R&D.
TTCN-3:: Testing and Test Control Notation version 3 ‎<<_1, [1]>>.
= References
[[_1]]
[1] ETSI ES 201 873-1 v3.2.1 (2007-02) +
The Testing and Test Control Notation version 3. http://www.etsi.org/deliver/etsi_es/201800_201899/20187301/03.02.01_60/es_20187301v030201p.pdf[Part 1: Core Language]
[[_2]]
[2]
User Guide for the TITAN TTCN-3 Test Executor
[[_3]]
[3]
EPTF Core Library for TTCN-3 toolset with TITAN, Function Specification
[[_4]]
[4]
EPTF Core Library for TTCN-3 toolset with TITAN, User Guide
[[_5]]
[5]
EPTF Core Library Execution Control, Function Description
[[_6]]
[6]
EPTF Core Library for TTCN-3 toolset with TITAN +
http://ttcn.ericsson.se/TCC_Releases/Libraries/EPTF_Core_Library_CNL113512/doc/apidoc/html/index.html[Reference Guide]
[[_7]]
[7]
EPTF Core Library LGenBase, Function Description