TPT is a tool providing automatic test of embedded systems, particularly for control and regulation systems.

Since TPT is independent of the platform of test-execution MATLAB/Simulink models as well as C-Code can be tested. The generated C-Code can be either tested within Simulink (e.g Targetlink SiL-mode) or externally by simply creating an executable and using the exe-platform. The tests that can be performed on both platforms are identical.

TPT supports reactive tests, that is to say tests, which can react on the system's behaviour during the test execution. Particularly when testing control systems, this possibility is essential because test cases mostly show a reactive nature in these fields.

TPT can be very flexibly applied to almost all test and development environments for embedded systems. Such environments can be variously complex, ranging from a simple C development environment to a complex HiL integration test bench. If TPT is integrated with a test environment, TPT concentrates solely on the systematic modelling and automation of test procedures. More specific tasks, such as the activation of certain I/O interface cards for HiL test benches or code instrumentalisation for coverage analyses, continue to be performed by the tool environments that are specialized for these tasks. The interface between TPT and the environment has been kept clear and simple for a seamless integration. This means that TPT does not require the development or test environments to be changed, but can be used as a supplement in the established environments.

TPT allows the repetition of tests in different "in- the-Loop"-environments without modifying the test cases for the exchange between Model-in-the-Loop (MiL), Software-in-the-Loop (SiL) and Hardware-in- the-Loop (HiL). This is possible because TPT uses both a platform independent test description language and a platform independent test machine which can be integrated in almost any test environments.

TPT can be used on almost any test platform because it is simple to integrate. Examples are MATLAB/Simulink, TargetLink, Provetech:TA-HiL, LabVIEW, C-Code)

In order to be able to insert new elements into an automaton or to change existing elements, please ensure, that the topmost entry of the scenario tree is selected. You can quickly identify it, because it also is the only entry with a testlet icon.

TPT's Virtual Machine is able to process tests in real time with defined response behaviour. The response times of TPT test cases are normally given within micro seconds depending on the complexity and test hardware. The TPT-VM is implemented in ANSII-C and requires a memory of just a few kilobytes and can completely do without a dynamic memory allocation, allowing it to be applied in minimalist and environments with few resources too.

A step-size of 100 microseconds is feasible.

The VM can handle a couple of hundret inputs and outputs. This is also possible within MATLAB/Simulink

TPT test cases are modeled independently of the execution platform. This means TPT test cases can be executed in different execution environments like MATLAB/Simulink, SiL or HiL. Each platform needs different configurations in order to execute simulations. E.g. the MATLAB platform requires information which Simulink-model file is used while HiL-configurations need information how signals at the HiL are mapped. For that reason for each platform there exist a platform-configuration for each simulation environment. Sometimes it makes sense to have different configurations for one physical platform. By doing this a system under test can be tested in different environments like Model in the loop (MiL) or Software in the loop (SiL).

The execution of tests on HiL-systems is dependent on the HiL that is used. This is dependent also which software is used on the HiL. Dependent on the special configuration there exist additional execution platforms in TPT. For those may be additional plugins are required. Please contact info@piketec.com for additional information.

Tests can be run on a CAN-Bus. A CAN-description (.dbc-file) is required as well as a CAN-card and a specific plug-in for TPT which connects TPT to the CAN-Bus. Please contact PikeTec for details.

In each editable script window you can place your own script before the
'% -BEGIN'
and after the
'% -END'
tag of the original TPT script.

Since an assessment variables declared within an assessment script may remain undefined, as long as it has not been written, one may want to check, if a certain variable contains any time intervals at all, before running operations on it. This may easily be done by calling .getSize() on the desired variable, which then returns the overall number of intervals defined within the assessment variable. Needless to say, that a number greater than zero indicates, that the assessment variable contains non-empty intervals, otherwise it is empty.

In addition to the modelling of the test cases, the expected system behaviour for individual test cases should also be automatically tested in order to assure efficient test processes. TPT offers the possibility to compute the properties for the expected behaviour online (during test execution) and offline (after test execution). While online evaluation uses the same modelling techniques as test modelling, offline evaluation offers decidedly more far-reaching possibilities for more complex evaluations, including operations such as comparisons with external reference data, limit-value monitoring, signal filters, analyses of state sequences and time conditions. The offline evaluation is, technically speaking, based on the Python script language, which has been extended by specific syntactic language elements and a specialized evaluation library in order to give optimal support to the test evaluation. The use of a script language ensures a high degree of flexibility in the test evaluation: access to reference data, communication with other tools and development of one's own domain-specific libraries for test evaluation is supported.

Python libraries can be used in the TPT assessment. If the python-module "mymodule.py" that shall be used are located in the folder e.g. "c:\mypython_ext\moduledir" please start TPT with the option "-vm-Dpython.prepath= c:\mypython_ext\moduledir".

If for example the content of the Python-module "mymodule.py" is:
---------
def foobar():
print "foobar"
---------

The function "foobar" can be used within the TPT-assessment script as follows:
---------
import mymodule;
mymodule.foobar();
---------

Alternatively for TPT-versions 3.0.8. and higher the folder /tptplugins/assessmentengine/lib is included in the search path. This means that Python libraries that are located in that folder can be used within the TPT-assessment scripts.

Measurements are signals that are not part of the TPT test-execution but are measured using an external tool like INCA. When measurements are declared and when the measurement tool is configured TPT hands the list of signals to be measured to the measurement tool and gets the signals back after the test terminated. These measurements can later be used in the test assessments.

A single assessment variable or channel may be selected to be used in a table or a graphic, by inserting a select statement above the table or graphic and typing its name into its textfield. If you want to select more than one channel at one time, you may either list their names, separated by the symbol | (a vertical line) or use regular expressions, to select all names matching a certain pattern.

TPT presents the result of the test evaluation to the tester in a HTML, report, in which not only the pure information "success", "failed" or "unknown" can be depicted as the test result for each test case, but also details such as characteristic parameters or signals that have been observed in the test execution or computed in the test evaluation. The content of the test documentation as well as the structure of the document can be freely configured.