Frequently Asked Question
Press "Ctrl + F" to find the keyword of your interest.
If you wish to have a direct link access to the video timestamps, please follow these instructions.
Found this video helpful? Why not take the whole HIL Specialist course? A Certificate is waiting for you for free at HIL Academy.
Would you or your organization benefit from having these videos narrated in your native language? Contact us and let us know if you wish to contribute.
TRANSCRIPT
Hello and welcome to our second lesson on Typhoon Test.
In this lesson, we will show how to write and automate a test using Typhoon Test.
To perform this example, we will use the induction machine with vector control
example. This model is a closed-loop speed control of an induction machine.
First, let s save it in a different folder to build our tests without
changing the library model file. Let s click on save as, navigate to the desired folder,
and save it as model . After that, we can click on compile model, and we are ready to start.
Once the compilation is complete, we can open TyphoonTest IDE from Typhoon HIL Control Center.
In TyphoonTest IDE, you can select the environment, control your simulation with
the start and stop button, select the working environment, write your tests,
and much more. We will go through these functionalities throughout our course.
Let s click on Create New File, Save Script,
navigate to the folder where we have our model, and save it as test_speed .
The software will ask if you want to change the working directory, so let s click on
Yes , and select the same path where we saved the schematic and test file. This is used both
as the reference path for the code and where the report will be generated and stored.
On the left side, we have the API wizard tab, which is very similar to the one in SCADA. This
will help us select functions and add them to our test. There is also the Structure
tab that will help us write the tests.For our first test, let s check if it can
track the motor speed reference. We can start by clicking on Add test. In the new window,
we can write the test name as test_tracking , and a description such as:
Testing speed tracking capability . Click OK.
We can see that a code is added to the test file with the desired test name and description.
You can also edit the code manually, like deleting the comment and pass lines.
To load the schematics, we go to the API wizard tab, and in the field Add
Module to list , we select HIL API and set the alias for this library as hil.
Here you can see several modules you can import. You can look at these modules,
and others, in our Documentation Hub in the Typhoon HIL Control Center.
Here, we have documentation for HIL API, Schematic Editor API, SCADA API, and more. For example,
if we open the Typhoon Test API you can see all the available functions.
This documentation is also available on the web via the links provided in the Materials tab.
Coming back to TyphoonTest, we can see some of these same functions under the hil alias.
To begin with, let s search for load_model , and select it.
Here, in the window below, we can read the documentation for this function.
It is the same one from our Documentation Hub . In the last window,
we have the wizard that will help us parametrize the functions.
The first thing we need to do is load the schematic so that the wizard will
know the available variables. So, click on Choose , and Load model at the top.
Here, it is possible to select the .tse file as well as the .cpd file. If the .tse is selected,
the model will be compiled. Since we already compiled our model, let s load the .cpd file.
After loading it, the wizard recognized all the available variables from the model.
Now, to load the model, let s click on File Picker , and then browse for
the same .cpd file we just loaded, click on open , and finally hit Ok .
This is going to fill out the value for the file argument.
Since we will be running this using virtual HIL, we need to change the value of the
vhil_device to True . After that, we place the cursor where we would like to insert the code,
so let s click inside our function and click on insert function .
Let s change the code so the model path is relative to the working directory. This way,
it will not matter where you placed your files.The next command will be to start the simulation.
So, let s search for start_simulation , select it, place the cursor and click on insert function .
If we ran this example in SCADA , we would see that some variables are set at the beginning
of the simulation, such as: speed reference, machine load, and the current reference for
the direct axis. We need to do the same here.Let s start with the current reference value.
As it is a SCADA input, we can search and select set_scada_input_value . In the line scadaInputName
we click on choose , select SCADA inputs , and click on the green + sign. From the list
of options, we select id_ref , and click on OK . In the line value we can type the value 0.2 and
insert the code. Let's repeat this process to set the speed reference n_ref to 500 .
Finally, to change the machine torque to a constant value,
we can use machine_constant_torque function.
For the name click on Choose , select Machines , press the + sign,
and select the machine model name, indm .For the value, set it as 20.
The next step is to wait for the simulation to reach a steady state.
For that, we can use the wait function from the TyphoonTest Capture module.
Let s add this module from the module list, set the alias to cap , and click on OK .
Now we can search for wait , under the capture module,
and click on it. Change the value to 1 and insert the function.
Now we are ready to start the test capture. This will let us save signals
for analysis after the test, just like the Scope/Capture widget in HIL SCADA. For this,
we will be using the start_capture function.
Let s set the duration to 1 second and the rate to 100e3 Hz.
To select the signals, on the signals argument, click on choose , click on
Signals , click on the green + sign to add new lines, and select n_meas , Ia , Ib , and Ic .
Finally, click OK and insert the function.Now let s define a variable to delay our reference
step change. So, let s define time_before_step = 0.1 and then use the wait function again calling
this variable. We can do this either by using the wizard or typing it directly into the code.
Now let s configure the speed reference step. First,
let s create another variable n_ref and set it to 750. Let s change the speed reference,
just like we did before, but now let s use the variable n_ref to set the new value.
Finally, we can get the capture results. Since we want to use the capture data,
let s attribute it to a variable. The captured data is returned as a Data Frame,
from the Python module pandas , so let s call our data variable df . To obtain the capture
data we use the get_capture_results function from the capture module. Let s set wait_capture to
True , so the test will wait the full duration of the capture instead of interrupting it.
Now we are able to analyze the signal. In order to do so,
let s use a few functions from the TyphoonTest Signals module, here added with the sig alias.
From here, we will be using pandas syntax. If you are not already familiar with it,
you can check out the Python basics lessons earlier in this course.
The first function we will be using is stepinfo , which will extract
relevant information from a step response.
As signal, let s select the measure speed, and change the settling time threshold to 1.
Since we added a delay from the start of the capture until the change in reference, let s
evaluate the step response from there, by changing evaluate_from_time to our delay variable. Finally,
we can add a variable to save the returned value and insert this function to the code.
Let s use the assert_is_step function from the
signal module to check if the speed has the expected step response.
For signal, select the measured speed. The step should happen at the delay time, from around
500 to around the speed reference. So, let s set from_value as 495 to 505, to_value as the speed
reference plus-minus 15, and at_t from the delay to the delay plus 200 milliseconds. Let s also
change the strictness to 90%, allowing 10% of the signal to be outside of the allowed step region.
We can also check if the measured speed is constant at the end of the capture.
For that, let s use the assert_is_constant function. Here, let s set a smaller tolerance,
of plus-minus 5 around the reference, and evaluate the signal from 900 milliseconds to 1 second.
It is important to highlight that if the first assertion fails,
Pytest will not run the second assertion. To overcome this behavior, we can use a Pytest
plug-in called Pytest assume. This way, Pytest will run all assertions. If at least one fails,
the test will fail. If all of them pass, the test will pass. In order to do this,
we need to have each assertion inside a with pytest.assume statement.
Finally, we can add the stop simulation command, and we will be ready to run the test file.
To run the test, we can select among current file, working directory, and custom. The current
file option will run this file we have open, the working directory will run all the tests
that are available in this folder. In this case, both options will have the same effect.
The custom option allows us to select the directory or the file that we want to run.
We could also check the box select test by name , which is the -k option from Pytest, and
the select test by mark which is similar to the -m option.
Before we run the test, let s create a couple of errors in our code and see
how that would look like. Let s add some characters to a library we are
importing and change the variable time before step to time before .
To run our test file, we select working directory and press the play button.
If the option open report box is marked, it will automatically open the test report.
As you can see, the report opened without any information. That is because there was an error
while collecting the tests. In this case, go back to the TyphoonTest IDE console, where
you can read the log and identify the error.Let s fix this error and run the test again.
Now the test is yellow, indicating it is broken because there was an error during test execution.
By opening the test, at the very top or bottom, we have the reason why it is broken.
By clicking on it, we can see with more details and exactly where it is broken,
making it much easier to identify errors. Let s also fix this one and run the test.
After the test starts, we can check the Test Run and Console tabs.
The Test Run tab shows all the collected tests, which test is running, the status
of executed tests, the execution time for the setup, test, and teardown stages. The console
shows a live log of what is happening during the test execution, so you can follow the procedure.
So, let s check the Allure report. On the top left, we can see the number of test cases,
the percentage of passing and failing tests, and the total testing time.
You can click on each test in the Suites section to look for more details.
Here, all the API functions are shown in the report.
We can see the simulation time of this specific test, its description, and the time of each step.
The first step was to load the model, start the simulation, set the value for id_ref , torque, and
speed. After that, we waited 1 second and started the capture, changed the speed reference, and got
the capture results after the defined duration. The API function automatically added the images
from the capture for all the selected signals, in this case Ia , Ib , Ic , and the measured speed.
Now let s check the step info, where we have the rising time, undershoot, overshoot,
settling time, ripple, and more. Here you can see the results either in the image or
numerically, by expanding the Results .Finally, we have the assertion functions,
where you can expand them and take a better look at the results.
Now we have a working test and can use it to test many more cases. We can parametrize the test to
check the performance of several operating conditions and optimize its execution by
migrating some portions of the test to a fixture. First, place your cursor on top of the function,
so the fixture will be placed at the top. Select the tab structure , click
on add fixture , change the name to load model , select the scope as module , and click on ok .
After that, let s cut and paste the code for loading model,
starting the simulation, and initial parameterization into the fixture setup.
Also, let s move stop simulation to the fixture teardown.
Now, let's add another fixture to return the speed to a default value.
Click on add fixture , change the name to return_to_500 , leave the scope as
function , add the load_model fixture in the fixture field, and click on ok .
Let s move the code for returning the speed of the system to the initial condition to the fixture.
Now we can parametrize this test for different speeds and loads, so let s select test_tracking
and click on edit . In the new window, we need to add the fixture return_to_500 . Now
we can parametrize the fixture. There are a couple of options to parametrize the test,
so in this first demonstration we will use tables. Let s say we want to test four different
speeds. Let s add two columns and four rows. Let s rename the columns to n_ref , with values 750,
750, 1000, and 1000 and the other column to load with values 10, 30, 10, and 30. After that,
we click on ok and it will update the test with all the test cases we would like to test.
After that, we need to delete the hard coded speed reference,
and edit the machine torque with the provided load .
A different way to parametrize the test is by adding the speed and load parametrization
individually. This second approach is more suited when you want to test all combinations
from different variable arrays. Just keep in mind that as we covered in the Pytest Basics lessons,
the parametrization order changes the test execution order, which may in turn affect
your test results.After that,
we are ready to run the test again, so let s press the play button.
Let s take a look at the results, for all four test cases. As expected,
the first test has a longer setup, since it is loading the model with a module scope fixture.
Thus, the setup times of the other tests are close to zero. It is also possible to see that
most of the time was spent on test execution, with close to zero time spent on teardown.
If we open the test report, we can see that one of the tests passes and the others failed.
Let s take a closer look at the first test that failed.
At the top, you can see the reason why the test failed.
Here, it did not comply with the 90% tolerance, since the signal stayed inside
the allowed region for only 79% of the time. By clicking on it, we can see more details.
In the parameters section, we can verify the parameters used for this test case.
Also, we can check the Set up stage, where we have the setup of all the fixtures used by the test.
Here, we see loading the model and returning the system to the default values.
Just as before, we can look the test results in more details by navigating though the report.
In this lesson we learned how to run tests with the HIL and to
optimize tests using fixtures and parametrization.
In the next lesson, we will enhance this test by adding more signal analyses to it.
