Remote control of ecu.test¶
At present there are the following possibilities of executing ecu.test automatically by means of different software
All of these mechanisms internally access the running ecu.test instance via a local network connection.
This connection uses port 8000 by default.
If said port is in use by another program, another port number can be configured by manually creating a registry value:
For this purpose, a DWORD-Value xmlrpcPort stating the desired port number needs to be
created at HKEY_LOCAL_MACHINE/Software/tracetronic/ecu.test 2026.3
In order to make the setting different from the system-wide configuration for an individual user, use the HKEY_CURRENT_USER branch instead of HKEY_LOCAL_MACHINE.
Two variants are explicitly available under Windows:
Instance with graphical user interface: ecu.test.exe
Runner as console application: ecu.test_runner.exe
Command line (batch interface)¶
The command line can be used to start and control ecu.test automatically. For example, a test configuration and test bench configuration can be specified and loaded. Packages or projects can also be opened and executed.
The command line interface of ecu.test can be used under Windows, Linux or in the Docker container.
Executing a package or project¶
The subcommand execute can be used to start ecu.test with a single call, execute a package or project and then quit ecu.test again.
Arguments¶
Argument |
Description |
Notes |
|---|---|---|
|
[optional] Output help on using the subcommand |
Lists all arguments of this command |
|
The path to the ecu.test workspace to be used for execution |
Absolute path or relative to |
|
[optional] Path to the test configuration to be used for execution |
Supports absolute paths, paths relative to the Configurations directory (specified in the settings of the workspace), as well as library paths in the format |
|
[optional] Path to the test bench configuration to be used for execution |
Supports absolute paths, paths relative to the Configurations directory (specified in the settings of the workspace), as well as library paths in the format |
|
[optional] Path to an empty directory where report files should be saved |
Absolute path or relative to |
|
Path to the package or project to be executed |
Supports absolute paths, paths relative to the Packages directory (specified in the settings of the workspace), as well as library paths in the format |
Return codes¶
When using ecu.test with GUI, the command returns immediately and always with the return code 0.
When using ecu.test without a GUI, the log output is displayed in the console
and the command returns either after an error (return code 1) or after completion of the test
with a return code that is related to the test result.
The possible return values for this case are listed in the following table.
Return code |
Description |
Notes |
|---|---|---|
|
The executed test has the result SUCCESS or NONE |
|
|
The test carried out has the result INCONCLUSIVE |
|
|
The executed test has the result FAILED |
|
|
The executed test has the result ERROR |
|
|
An error has occurred during execution. The command could not be executed correctly. |
Information on the cause of the error can be found in the log. |
Info
In the Windows command line, the return code of the last executed command can be
determined using echo %errorlevel%.
Examples¶
All paths must always be specified on a platform-specific basis.
For example, a command under Windows could look like this:
ecu.test execute --workspace C:/Data/ecu.test --testbenchconfiguration local.tbc --testconfiguration myTCF.tcf myPackage.pkg
Under Linux, an example command looks like this:
ecu.test execute --workspace /home/Data/ecu.test --testbenchconfiguration sub/local.tbc --testconfiguration myTCF.tcf subFolder/myPackage.pkg
Controlling an instance of ecu.test¶
ecu.test can be started automatically by command line with a configuration and a package or project, which then can be executed. If ecu.test is running already, that instance is used.
Arguments¶
All parameters can, and in the case of configurations should, be combined.
Argument |
Action |
Notes |
|---|---|---|
|
Indicating another setting directory than |
|
|
Indicating another ToolLibs.ini |
|
|
Starting in a specific workspace |
|
|
Start ecu.test in automated mode, suppressing dialogs that need manual action |
|
|
Waiting for a started ecu.test instance to be ready |
|
|
Loading a test configuration |
|
|
Loading a test bench configuration |
When loading configuration files, after starting ecu.test the configuration is loaded and neither the test nor test bench configuration editor is opened. |
|
Open a package or project, test report or test (bench) configuration |
|
|
Open a package or project, test reports or a test (bench) configuration in URL notation |
|
|
Open a package or project, test reports or a test (bench) configuration in URL notation with a path relative to the workspace |
When open the configuration files the configuration editor is opened according to the configuration type. |
|
Open a package, test reports or a test (bench) configuration in URL notation with anchor |
When opening a test report you can specify an anchor with an id inside the test report. The item with the given id will be selected as soon as the report viewer is shown. The report viewer allows you to copy such a URL by clicking Copy Link in the context menu of an report item. |
|
Execute an opened package or project and wait until the execution has finished |
|
|
Wait until execution of a package or project has finished |
only in combination with |
|
Start the web API for ecu.test code |
Can both be specified upon starting ecu.test, as well as when controlling an already running ecu.test instance. |
|
quit a running ecu.test instance |
|
|
force quit a running ecu.test instance |
Return codes¶
If the ecu.test process is terminated due to an error, an return code is returned which is different from 0:
Return code |
Description |
Notes |
|---|---|---|
|
Command executed successfully |
|
|
An error has occurred during execution, e.g. due to a timeout when starting the instance |
Information on the cause of the error can be found in the log |
|
No new instance could be started |
e.g. because an instance is already running on this port |
|
Missing license |
Examples¶
All paths must always be specified on a platform-specific manner.
For example, a command under Windows could look like this:
ecu.test.exe --workspaceDir C:/Data/ecu.test
Under Linux or within a Docker container respectively, an example command looks like this:
ecu.test --workspaceDir /home/Data/ecu.test
rem start ecu.test with indicated configuration
start ecu.test.exe
timeout /T 10
ecu.test.exe -w
timeout /T 5
ecu.test.exe -c "C:/Data/ecu.test/Configurations/empty.tcf" -b "C:/Data/ecu.test/Configurations/local.tbc"
rem wait for started ecu.test to be ready
ecu.test.exe -w
rem open package....
ecu.test.exe -o "C:/Data/ecu.test/Packages/DrivingCycle.pkg"
rem execute package....
ecu.test.exe -r "C:/Data/ecu.test/Packages/DrivingCycle.pkg"
rem further actions possible
rem quit ecu.test
ecu.test.exe -q
Runner as a console application¶
In addition to the GUI variant, ecu.test_runner also provides a faster console application that does not require a graphical user interface.
This offers considerable advantages in terms of execution speed, particularly when automating tests.
A command line that uses the runner could look like this:
ecu.test_runner execute --workspace C:/Data/ecu.test myPackage.pkg
Installing external Python libraries via command line¶
External Python libraries can also be installed via command line, e.g.:
ecu.test_runner task install-python-libraries --workspace C:/Data/ecu.test --timeout 90
COM API¶
Along with the very simple control by batch files ecu.test possesses also a COM server which provides clearly more possibilities of controlling and requesting information.
The commands of the ecu.test COM interface are described in detail in the API documentation under
COM API. Furthermore, the use of the COM interface is demonstrated in
<installation path>/Help/api/ExampleCOM using the following two examples.
Excel: Execute a package via the ecu.test COM interface and insert the result into the Excel table.
C#: Execute a package via the ecu.test COM interface.
Info
The COM server registration of ecu.test has to be activated during installation.
Otherwise, the COM API will not be available.
If another version of ecu.test has been uninstalled, the COM API will still work for a
remaining version, but you will have to provide the version number explicitly in the Dispatch
call - e.g. win32com.client.Dispatch('ecu.test.Application.2026.3') or
win32com.client.Dispatch('ECU-TEST.Application.2023.3') for versions prior to 2023.4
COM server registration can be performed again if you start the installer once more and select the option “change” or “repair” respectively. If this does not help, COM server registration may also be performed manually via command line:
~ecu.test program folder~/ecu.test_COM.exe /register
You will need admin privileges in order to do a system-wide registration. As an alternative,
the additional option /peruser performs the registration for the current user only.
The call then looks like this:
~ecu.test program folder~/ecu.test_COM.exe /register /peruser
Info
Additional information about COM API can be found at API references
REST API¶
To control the test execution remote of ecu.test, an OpenAPI based REST API exists as an alternative to the COM API.
Additional information about the REST API can be found in the API documentation .
ecu.test execution plugin¶
The ecu.test execution plugin provides an easy integration and control of ecu.test and Tool Server in the continuous integration server Jenkins.
More information about installation and configuration of the plugin can be found on the projects Github-Repository.