Skip to main content

Developing and Testing Control Systems with MATLAB and Simulink

Testing designs continuously is critical for developing future-proof controls systems. We will cover testing tasks along your development path, from testing early prototypes, hardware-in-the-loop testing of your digital twins up to making sure embedded controllers are validated and verified. Benefit from the interactive real-time testing workflows based on Simulink Real-Time™ together with Speedgoat testing solutions. The webinar offers you an engaging learning experience by exposing you to a broad set of real-life testing scenarios, including real-time interactions with digital twin simulators and physical systems, such as motion sensors, electric motors, and robot manipulators.

Topics that we will cover include:

  • Run mixed-signal and real-time measurements and analysis
  • Perform interactive signal and parameter instrumentation with Simulink and MATLAB® apps
  • Prepare and execute automated runs with Simulink Test and MATLAB® scripts
  • Co-simulate with third-party environments 
  • Learn how to test with greater flexibility with standalone test setups
  • Quickly adapt to new project needs with reconfigurable I/O

Video Transcript

Hello everyone, and thanks for joining this webinar!
My name is Timo, and I'm an Application Engineer at Speedgoat.
In today's webinar, I am taking you on a deep dive into the joint MathWorks and Speedgoat solution for real-time testing. 
I will show you how this can simplify the way you develop, deploy, and test controls.

Maybe you are not familiar with neither MATLAB and Simulink, nor Speedgoat. So let me start by sharing how engineers and scientists have used this solution to develop and test innovative control systems.

Let's start with automotive systems.
Engineers at ClearMotion are transforming our driving experience by developing highly dynamic active suspensions systems.
Tata Motors accelerates the development of autonomous vehicle controls.
LeClanché and Proterra drive the electrification of mobility by developing lithium-ion battery packs and zero-emission buses.
And Flanders Make creates multi-load drivetrain test benches for heavy-duty vehicles.
Engineers use our solution to advance powertrain controls for more electric aircrafts and nano satellites, like FVA Aachen and Alto University in the aerospace domain.
Teams focusing on hyperloop transportation, for example at TU Munich, build pods aiming to revolutionize terrestrial transportation.
In the domain of energy supply, scientists perform unprecedented experimental research, like peers at CERN who develop controls for particle colliders, or engineers at SuperGrid Institute who create power converters for next-generation super grids.
Applications of real-time test systems in healthcare can have a direct impact on our well-being. For example roboticists and doctors at Corindus research, who work on novel robot-assisted surgery techniques, even allowing remote control.
Specialists at Sonova, Cochlear and ICanHear aim to improve the acoustic experience of hard-of-hearing persons.
Patients that have difficulty walking benefit from Humotech's solution of a custom-controlled ankle-foot prosthesis. Or those with tremor symptoms benefit from vibration cancelling wearable devices by STIL.
Solution providers in industrial automation leverage bypass prototyping to accelerate control design for CNC machines, like our customer Homag. IAV, another customer, applies digital twin testing of their PLCs for virtual commissioning.
So, independent of the industry or use case, we take pride in our work that helps accelerate breakthroughs for the benefit of future generations.
Let's now have a closer look at how we are enabling these teams to work more efficiently.

The key enabler is an integrated testing solution composed of Simulink Real-Time, the real-time test and simulation solution from MathWorks, and scalable Speedgoat real-time target computers equipped with I/O.
So when you start real-time testing of your controls, you don't have to leave Simulink or MATLAB, and you don't need to be experienced in embedded coding. Just connect to hardware with a few clicks, switch back and forth between real-time and desktop simulation seamlessly, and use the same solution in every testing stage.

During the early design stages, you probably want to tweak the performance of your newly designed controller, digital signal processing, or vision system.
Or you want to verify that your design operates correctly in real-world conditions.
In the deployment stage, you may want to test your embedded controller using Hardware-in-the-Loop testing.
Test using virtual networks, automate testing of defined test cases, employ function bypassing and calibration; you name it.

When working on a test cell or a new experimental setup, you probably need flexible yet powerful compute hardware. It allows you to acquire and process data with high bandwidth and low latency from multiple synchronized sources.
It also enables you to characterize sensor or actuator system dynamics. As a result, you can implement new monitoring and control strategies quickly.

Working on one or all three of these test use cases requires you to have a set of capabilities at your disposal.
I will highlight the capabilities briefly and, in the following, provide you with tangible workflow examples.
You acquire and visualize real-time data from mixed sources and perform interactive analyses with minimal effort and no coding.
You trigger specific signals and test profiles.
You create instrument panels that make it easier to interact with your test application, or tweak parameters to influence performance and switch between testing scenarios.
You pre-process data and simulate your complex physical systems in open or closed-loop manner.
You author complex test scenarios and automate repetitive tasks.
You co-simulate and interact with software environments of your choice.
You deploy test application and run them independently from the development or host computer.
I hope you agree with me on the above capabilities.
My goal for this webinar is to show you how MATLAB and Simulink together with a Speedgoat real-time target computers enable you to use those capabilities and benefit from them. 

So, for the remainder of this webinar, I will share a broad set of real-life testing examples with you.
And I will split it into three main parts:
In part one, I will show you how you can use Simulink as the primary interface for interactive and automated tests.
In part two, we will be using MATLAB and more programmatic ways to automate testing and instrument test applications. 
And in part three, we will investigate standalone operation and interfacing with third-party tools.

Alright, let me get started with part one and our first example.

When starting real-time testing of a new controller design, you often need to integrate new components, like sensors and actuators, and set up the required interfaces.
Perhaps you are working on a new satellite attitude controller or a cellphone camera stabilizer, and it is now time for you to interface with inertial sensors. Or, like our friends at Flanders Make, you are designing a monitoring and control system for a drivetrain test bench, which relies on high grade accelerometers and strain gauges.
I have prepared a simple example that shows how you can combine Simulink with Speedgoat hardware to support you on such tasks. 
More specifically, we will look into how to connect to your sensor, perform spontaneous real-time measurements and data pre-processing.
As shown in the slide, I am using a 9-axis inertial sensor. This sensor communicates over an I2C protocol, a common serial interface. To set up and test the sensor, I use a Speedgoat Unit real-time target machine, our smallest form factor. 
So let me switch to MATLAB & Simulink and start my demo.

In the Simulink model, you can see on the left side the subsystem where we take the sensor readings from the IMU. To communicate with the sensor, I'm using the IO397 configurable IO module. Configurable means that it can easily be reprogrammed, with configuration files that enable different functionalities, such as the I2C interface which I am using here.
For communication, we need the device ID, and register addresses to read from, or write to. I set up two write signals here to configure the sensor, and then we want to continuously read out 14 bytes of data containing the accelerometer, temperature, and gyroscope data. 
I have already selected these output signals for logging to the Simulation Data Inspector. To log additional signals, just click on it and choose "Log Selected Signal". This is one of the easiest ways to log signals, which I'll be doing many times throughout the different examples today.  
Directly from the Simulink toolstrip, I can now click "Run on Target", which will compile, deploy, and run the model on the Speedgoat real-time target machine.
While the model is running in real-time, I can observe the logged signals in the Simulation Data Inspector and verify that we are in fact getting sensor data, and the signals reflect the movement of the sensor. 
Now let me also show you some other options to perform spontaneous measurements. One of them is the Scope, which I can add using either the Simulink block, or also, just right click the signal and select "Create & Connect Viewer", and then "Scope", which will link a new scope without adding additional blocks to the model. And the other tool I'd like to showcase is the Spectrum Analyzer. 
If you have connected multiple viewers and would like an overview, you can open the Viewers & Generators Manager. Select an entry to highlight the linked signals, and add or remove them easily. 
With these additional tools connected, let's run the model again, so we can observe the live measurement data.
Scopes provide many useful features beyond simple data logging. Similar to an oscilloscope, it can, for example, automatically detect and label signal peaks, do curser measurements and bilevel measurements, or you can use triggered mode to analyze specific signal transitions.
Maybe you're also interested in a frequency analysis of the signal, for example to identify unwanted noise frequencies you'd like to filter out. We can use a spectrum analyzer block for this, and again capture live sensor data while running the model in real-time. The spectrum analyzer also offers various settings and viewing options for detailed signal analysis.
We could use this knowledge to design a filter and filter out high-frequency noise and low-frequency drift of the sensor. To determine optimal filter parameters for the gyroscope, we might want to integrate the angular velocity measurements to get the sensor orientation. 
By comparing the orientation calculated from the raw and the filtered sensor data, we can fine-tune the filter parameters to our specific needs.

Allow me to share a success story by our customer University of Alabama, who has used Speedgoat and Simulink Real-Time to develop a real-time monitoring and active damping control system for pedestrian bridges.
Besides supporting in controller testing tasks, Speedgoat hardware enabled this team to easily interface with many different types of sensors using a single hardware unit.
And another reference, this time from TAE Technologies, who focusses on clean fusion energy.
Their fusion reactor named Norman handles hot plasma of around 30 million degrees Celsius. A key challenge is keeping the plasma well-centered in the reactor, which requires state of the art real-time data monitoring and feedback control techniques.
Controls require magnetic field data from about 400 sensors to be monitored and logged at 2.5 MHz. 
For this, TAE used 4 data acquisition and 2 compute systems that communicate using multi-gigabit transceivers and fiber optics, allowing for super-fast and deterministic data transfer while meeting best in class IO latency.
Note that Simulink and Simulink add-on products offer you additional viewers supporting real-time visualization of data, like for example the constellation diagram, the logic analyzer or the bird's eye scope.

For the next 3 exercises, I am going to focus on electric motor controls. 
My goal is to show you how the same hardware can used to support you across different stages of your development project.
In all three examples, I will be using the same Baseline real-time target machine and simply reconfigure its I/O interfaces to best fit the different project needs.
For your reference, these examples are covered in the Speedgoat Electric Motor Control Reference, which you can download online for free.

For my first electric motor control example, I want you to imagine you are testing your newest motor controls in desktop simulation.
To expedite pace and quality of your tests, you decided to create a higher fidelity model of your brushless DC motor.
Datasheet parameters gave you good starting point, but you would like to refine model behavior with real motor data, so the model becomes a true digital twin.
So, I'm going to introduce you to capabilities such as stimuli generation and on-target recording of real-time measurement data.
We will then see how to use experimental data to automatically fine tune parameters of your Simulink model.
Let's start by taking a look at the Simulink model used for desktop simulation.

Here we have models for both the field-oriented controller, as well as the electric PMSM or permanent magnet synchronous motor. If we look inside the plant model, you can see that the motor is modelled as a Simscape network. This will provide great model accuracy with the right parametrization.
We have different ways to apply input signals to our model. For now, I want to manually define some custom control inputs, so how can this be done easily? A quick solution is to use the Signal Editor block. As you can see, we have already pre-defined multiple signal scenarios, which we can select from the drop-down menu. Adding new signals and scenarios is also easy, with the signal builder app. Here I can for example add a blank signal, and then simply drag and drop points and lines to build the signal. I can also draw free-form or use mathematical expressions. And you can always correct the values of each point using the table below.
For our test, let's just use the pre-defined coastdown scenario and run it. This will tell the controller to spin up the motor to a constant velocity and turn it off again. How fast the motor slows down depends on parameters such as the motor inertia and various friction coefficients. If we compare the response of our Simulink model to the behavior of the real motor, we can identify these parameters to make our plant model accurately mimic the real motor.
So, to get the real motor response now, let's switch over to our other model variant. You can see it looks quite similar, with the same inputs and controller subsystem. But the plant model has been replaced with I/O interfaces to control the real motor. I'm using the same configurable I/O module again, this time for PWM generation, quadrature decoding and analog and digital signals.
I'll set the control inputs to the same coastdown scenario, and with a single click, compile and run the model on the real-time target machine. You can see the video of the motor performing the experiment.
We can use the simulation data inspector to easily compare signals from different runs, also to compare desktop simulation to the real-time application. The red line in the plot here is the rotor velocity from our real motor experiment, and the blue line is from our desktop simulation model. We can see that the controller speeds up both the plant model and the real motor to the commanded velocity, but the coastdown behavior at the end is different, indicating that our parametrization of the motor model can still be improved. 
Now we could manually dig into the model, change some parameters, and perform additional runs for comparison. But I want to introduce you to Simulink Design Optimization, which will allow us to automatically find an optimal set of inertia and friction parameters, so that the response of the motor model matches the real device. 
Let's open the Parameter Estimator app directly from the Simulink toolstrip. To save us some time, I have prepared a session which is linked to the plant model, I have chosen the parameters we want to tune, and added the velocity data from the experiment with the motor.
If we click "Plot Model Response", we also get the simulation output for the current set of motor parameters. 
Now we are ready to start the optimization process.
We can observe the progress in the plot. As the parameters are adjusted, the response of the digital twin gets closer and closer to that of the real motor. At the end, we have a new set of optimized parameters, which we can directly fill into the model, and our motor model now very accurately replicates the real motor's behavior.
We are going to reuse this fine-tuned plant model again when we talk more about Hardware-in-the-Loop testing. But first, let's go back to the presentation.

Our customer Preceyes developed the world's first eye-surgery robot using a very similar approach.
While constructing a model of the robot's kinematics and dynamics, the engineers conducted system identification, using Speedgoat target hardware with EtherCAT interfaces to excite the robot's motors and measure the response.
The team then used the same target hardware to develop a controller model that processes inputs from a joystick and around 60 sensors, and generates motor commands in response to the surgeon's movements. 

At some point you will want to prove that your design works well in real-world dynamics using the real motor and electric drives.
While doing this, you will certainly need to iterate on your design, tweak parameters and continuously monitor real-time performance.
And this is exactly where the integration of our solution shines out.
Let's see in an example.

In this demonstration, we'll use again the model where we simulate our controller in real-time, and drive the real electric motor through the I/O interfaces. This time, we want to use the real-time workflow to perform Rapid Controller Prototyping, meaning we want to change some control parameters and directly observe the changes in control performance.
The field-oriented controller employs PID control for the velocity control loop. At this point, we have already gotten a reasonable estimate for the controller gains through testing against our desktop simulation model. Now it is time to verify and fine-tune the control parameters against the real motor. What I want to point out here is that many parameters, such as the P and I variables here, can be adjusted even during runtime of the real-time application, and changes don't require a rebuild of the model.
I've started the model again, and you can see the motor and the live data from the Simulation Data Inspector. I've added some dashboard controls as well, to quickly change the speed command directly from the Simulink canvas, which allows me to see the effects of variations in the controller gains.
Depending on your application, you might need to update multiple parameters simultaneously, to test a desired effect. Apart from test automation, which we'll talk about later, this is also possible directly from Simulink. We activate Batch Mode on the real-time tab, and then we can adjust all the parameters we need. The changes will only be uploaded to the target machine once we click "Update All Parameters". To switch back to normal mode, simply click batch mode again to deactivate it.
MATLAB and Simulink also offer you different tools for PID tuning, and automatically find optimal controller gains to achieve a desired response.
And one more thing before we move on; I already showed how we can modify parameters without rebuilding the model, but that's not all. Maybe you realize during simulation that you need to log some additional signals. With the latest MATLAB release 2021b, additional signals can be added for logging at any time, without rebuilding the model. This is done by adding an instrument object, and then simply selecting the signals by checking the checkbox. The selected signals will also be logged to the Simulation Data Inspector. You can also use the buttons from the Simulink toolstrip to highlight existing instruments and add or remove them. And this wraps up the demonstration for the moment.

Let's continue our development journey and talk about hardware in the loop testing of our digital controller, using high-fidelity and deterministic plant simulation and automated testing.
Before I start my next example, let's first talk about some of the reasons why you would want to do Hardware-in-the-Loop testing.
Let's say our electric motor is part of an electric vehicle powertrain. These are dangerous systems when energized, and you might not want to mess around with these in a prototyping stage. You can maximize safety and minimize the risk of damaging equipment by testing your controller with a virtual system first.
Getting time with a dyno setup or in a power lab might also not be an easy thing to do. So every time you can offload that time to a virtual HIL setup will benefit you in time and costs.
And finally, it's rare that everything just lines up the way we planned. Automated testing with a virtual test bench allows you to be less dependent on time schedules and hardware lead times and increase the quality of your testing.

So for automated Hardware-in-the-Loop testing, I now want to use a test harness to apply different stimuli to the model's root-level inports. A test harness is an encapsulating Simulink model, which allows us to connect multiple test inputs and verification statements to our system under test.
A test harness can quickly be created for any model by right-clicking and selecting "Test Harness" - "Create for Model". In this case though, I already have a harness in place, which I can quickly switch to using the perspectives view.
You can see that this looks like any other Simulink model, but it includes a referenced subsystem with our system under test, and I'm using the "Test Sequence" block to define the input signals for the different test cases.
The test sequence implements closed-loop testing using step transitions. At one second, the motor is turned on, followed by a verification step where we check that the measured velocity lies within tolerance. We repeat this process with a velocity command in the opposite direction and verify again.
We can run the test sequence in desktop simulation first, add break points to the sequence for debugging, and then manually deploy the model for real-time execution.
But you see, we have ended up with multiple different models and test harnesses already. We can avoid managing them all manually, and instead use the Simulink Test Manager for full test automation of our test management, execution, and evaluation, for both desktop simulation and real-time tests with hardware in the loop.
We can open the test manager directly from the Simulink toolstrip and see our pre-built test setup. 
The first test is named MIL, or Model-in-the-Loop, so this will run entirely in desktop Simulation. The second one for Rapid Controller Prototyping, is then a real-time test, which means the model will be executed on our real-time target machine. You don't need to create each test from scratch here. We can easily make a copy of our desktop simulation test and convert it to a real-time test. Like this, you can maintain the configuration, such as assessments or parameter overrides.   
I'll be using the hardware-in-the-loop test now, which is a real-time test set to run on our default target machine. At the top we also define the model and test harness to run. In the other sections, we can for example override model parameters. I will change the inertia of the disc driven by the motor, to see how our controller responds to that. And finally, we have multiple assessments which will be automatically evaluated, to determine if our test was successful. These come in addition to the verify statements in our test sequence block.
So let me just run this test case now, by clicking the Run button.
Our test is now run for each parameter set automatically, which takes a bit of time, so I'm fast-forwarding a bit.
In the end, we get all of the results nicely structured, and can immediately see the tests were passed. For more detailed analysis, plots of all the signals and outcome of the verifications can be visualized.
Once we have a complete set of results, we may want to export them for a later analysis or documentation. 
We can select the test cases we want to generate a report for and click on the Report button. There are multiple fields we can customize, and checkboxes to enable which content we want to publish.
I'm going to create a report in PDF format including plots of the assessments and simulation outputs. After just a few seconds, we get the complete report for later analysis.
So, while this was a real-time test case, your test suite can also include desktop simulation tests, or equivalence tests, where you verify that different models produce equivalent results.
You can then run the entire test suite in one go, saving you a lot of time. You don't even need to open Simulink anymore, as configuration, execution and evaluation is all handled by the test manager.
So, with that, let's go back to the slides to wrap up the first part of our webinar.

This is the perfect segue for my next customer success story form Schindler Elevator Corporation.
Most of the mechanical and electrical integration done by Schindler was happening in very late stages of development when all components were available. In 2016, Schindler spent around 3'200 hours with physical testing.
There was a strong need to reduce costs and frontload testing to earlier stages, and Schindler started adopting model-based design and hardware-in-the-loop testing.
They created a digital twin of the entire test tower and elevator components, which they call "Tower in a Box". This allowed Schindler to shift from physical to virtual and automated testing of embedded controllers.
Most of the tests can now be handled at a much earlier stage and without occupying real test shafts. 
The Tower Box approach is currently used worldwide, in all Schindler's test facilities. A complete software release test now takes about one night, instead of four weeks.

Many of our customers have been using our solutions in a sort of hybrid scheme, where digital twin HIL simulators are used to frontload virtual testing in early controller prototyping stages. 
Also, for aerospace and automated driving applications, it is actually not uncommon to find our systems combined with powerful 3D simulation tools, making it easier to visualize and understand complex testing scenarios.

This is exactly what a brave team of researchers did at the Technical University of Munich.
The TUM autonomous motorsport team has been developing a software stack for fully autonomous, all-electric racecars.
A Speedgoat Mobile machine serves as the vehicle electronic control unit, or ECU for short, doing sensor fusion, highly performant motion control and monitoring of the vehicle components.
But test time on the racetrack is extremely limited, and the team needed to verify their algorithms often. 

They decided to model a complete virtual vehicle digital twin, which runs in real-time on a second Speedgoat target machine.
The data exchange between the two machines uses the same CAN interface as on the real car.
This means the ECU doesn't see any difference between the real vehicle and the digital twin.
Furthermore, the team created a virtual representation of the racetrack from sensor data.
Co-simulation of Simulink Real-Time with the Unreal Engine for visualization enabled fully virtual testing of the complete software stack for sensor fusion and motion control in real-time.

So far, I have shown you how Simulink Real-Time and Speedgoat can simplify real-time testing of your controllers using Simulink.
But in many situations, the dependency on Simulink might not be justified, both from a cost and benefit perspective.
Perhaps your team is only focused on testing and is not necessarily involved in the design.
And for testing, you may actually want your team to test without worrying about model details and run interactive and automated runs directly through user interfaces or scripts.

Our solution was developed and integrated with these needs in mind, and most of the powerful instrumentation and testing capabilities we have seen so far, are also available from your MATLAB.
So, you can, for example, use MATLAB Apps to facilitate interactions with your real-time application, and use scripts to automate and expedite testing.
But there is more:
As of R2020b, Simulink Real-Time no longer requires Simulink, Simulink Coder, and MATLAB Coder to instrument and interact with pre-built real-time applications. 
This lets you test with greater flexibility, with cost-effective solutions that can easily adapt to your needs.
So, in this second part of the webinar, I will focus on MATLAB-based testing. 
Let us start with MATLAB scripts, which give you unlimited interaction options with your real-time application, and revisit our motor control demo from part 1, this time using only MATLAB.

Automated execution through scripting is key for real-time testing, and MATLAB offers you great features that make coding and personalization very easy. 
Live scripts allow you to have both formatted text and executable code blocks, and divide your script into sections that can be run individually or all together. You can also add interactive controls, such as buttons, sliders, and drop-down menus.
I can, for example, add some slider controls to modify the gains of the velocity controller directly from the script. With this, I can set up and execute a closed loop test of our electric motor without ever opening the Simulink model.
The remainder of this section will then build the model, deploy it to the target machine, run it, and open the Simulation Data Inspector to view the results.
So, note that we can access the data inspector directly from MATLAB as well, and without Simulink. 
While the script is running, we can observe the motor performing the closed-loop control experiment, and the log data is automatically loaded at the end.
Additionally, we can also plot and visualize the data directly inside our live script.
In this example, I then go on to select the coastdown data and perform curve fitting, allowing me to estimate motor parameters by fitting my analytic equation for the motor speed to the experiment data. The main point here being that we can perform a full Rapid Control Prototyping workflow without Simulink, using MATLAB scripts to automate and evaluate each step.

Let's now talk about ways of opening up access to your real-time application for non-Simulink users or perform demonstrations using customized user interfaces.
So, for my next example, I want you to consider you are a robotics engineer that has been using Simulink and MATLAB to deploy and test a new robotized tester.
This new system is planned to be deployed worldwide and revolutionize the way your company performs functional testing of touch devices.
You just finished fine tuning of the supervisory controller using a Speedgoat with EtherCAT interface to control a 6 degrees of freedom manipulator. 
It is now time for you to design the user interface that will be later used by operators to run automated test routines. You have heard about MATLAB App Designer and its integration with Simulink Real-Time and want to give it a try.

Let's start with a brief look at the Simulink model, but I won't go into any depth here. We have some push buttons and indicators, for testing the robot right from Simulink, then some input and output interfaces, which use the EtherCAT protocol to communicate with the robot, and finally our main controller, which is implemented in Stateflow.
But what I want to focus on now is the user interface built with MATLAB App Designer. Here you can see the App Designer window and the app I have created so far. This is the design view, where we see a graphical preview of our user interface, which we can modify with just drag and drop.
There's a UI Axes plot, where I will display the phone screen image, and then we have some buttons and status lamps to interact with the robot. Of course, we need to code what is going to happen when each button is pushed, so this is done using callback functions. We can jump to the callback function by right clicking the UI element and select the callback, which will switch over to the code view. The grayed-out parts of the code are automatically created when you add an element in the design view, and we only need to add the core functionalities. Here, we are setting some parameters on the target machine using the setparam command.
Similar, for the lamp indicators, we have functions to set the color based on status changes.
What's still missing though are some buttons to interact with the target machine itself. A recent update to App Designer introduced new, pre-built buttons for Simulink Real-Time. These require no coding at all, taking a lot of work off my shoulders. I think I will need a drop-down menu to select the target machine, and a start button of course. And before we can start, we also need to connect to the target machine. And finally, it's always a good idea to have some status indicators.
As said, these buttons work without any additional coding, but sometimes you still want to add additional functionalities. In that case, you can still add another callback function. App Designer then creates the function stub, and you can simply add everything else you need the function to do.
When we're ready to test our app, just click the Run button, and App Designer will compile and start your app.

So now for the most fun part; Let's see our robotic touch device tester in action!
On the left side, you can see a screen capture of the MATLAB app I just showed you, and on the right a camera view of the robot. We only have to click a few buttons now, and the robot will do all of the work for us. 
First, we start the real-time application on the target computer, and the robot will automatically perform a homing movement. Then we proceed with telling the robot to unlock the test phone with the factory default pin code. Afterwards, we select to open the test menu, which is done by entering a standardized sequence on the dial screen. And finally, we run our test function, which will start and execute the touch screen test. On the direct video feed from the phone, we can clearly observe if all the checkboxes are turned green. This check could of course also be automized in a later step using image processing.
With the test successfully completed, the phone goes back to the test menu, and we will go back to the presentation.

To finish up part 2, I would like to introduce you to the newly designed Simulink Real-Time Explorer.
Once you generate code and deploy a real-time application, Simulink Real-Time Explorer will provide a single point of contact for interacting with real-time applications.
It allows you to manage multiple Speedgoat target computers and their configurations, allowing you to switch between test setups easily.
You can load new applications from the host computer or select one from the target computer.
You can easily select an application to run on startup, so that it starts execution as soon as the target computer powers on.
You also have access to all the signals and parameters and can easily stream and monitor signals of interest.
Model parameters can be identified for tuning, and there's a system log viewer to monitor and debug target activities.

Let's conclude with the topic of standalone operation and third-party interfaces and chat about how to interact with your test application without the need to have MATLAB and Simulink Real-Time installed.

You may want to open up interaction with the test system through an app that runs as a stand-alone executable.
Other times, all you need is to quickly check system status or update application parameters through a simple command-line interface.
Or you need to comply with project requirements which dictate application access to be done from a specific third-party tool other than MATLAB or Simulink.

So, let's first chat about desktop and web apps while referring to our previous robot example.
When the time comes to deploy your system and enable end-user operation, you can simply create a standalone desktop app with MATLAB Compiler and share your app royalty-free with all test operators.
In App Designer, simply use the Share button to create a standalone desktop app. You can add your information, a custom splash screen, and all the files needed to run the app. 
Click Package to start the build, and when the build is complete, the folder with your executable opens. 
This app can now be executed by anyone without requiring licenses, using the free MATLAB Runtime.
You can also package your apps as interactive web apps and share them using MATLAB Web App Server and then run them directly from the browser without installing any additional software.

Remember Schindler's user story and the Tower Box concept?
Schindler actually pushed the concept a bit further and deployed several MATLAB Web Apps to support all sorts of testing activities and enable end-users to do things like defining new test scenarios, configure elevator systems, as well as generating automatic reports.

For debugging and quick status checks, you can also interface with the Simulink Real-Time environment through the target computer command-line interface, for instance using an SSH connection, or simply connecting a keyboard directly to the target machine.
On the target computer, enter commands at the command line to do things like load, start and stop the real-time application, view the status monitor of the real-time target machine, load different parameter sets, or save the current parameters, and transfer log files to your computer.
Using an SSH utility to send commands to your target machine could even be done wirelessly from your cell phone.

We have seen how MATLAB and Live Editor can support you with in repeatable and interactive tests, but you may prefer using third-party environments to work with your real-time applications. This is possible using the feature-rich MATLAB API.
For instance, here we show a set of Python tasks that automate the process of building, downloading, and running a real-time application on the target, and the generation of an analog signal and its amplitude modulation.
Other languages like C++ or C# are also supported.
For more information about the API and various examples, please refer to Simulink Real-Time documentation.

Another common request is the support of ASAM XCP protocol and third-party measurement and calibration tools such as CANape by Vector and INCA by ETAS.
This is supported by Simulink Real-Time and Speedgoat with the native ASAP2 or A2L file generation and XCP supported on most Ethernet ports.
The example here models a damped oscillator with several tuning parameters, and we want to use the INCA tool instead of Simulink Real-Time for calibration.
When we build the model, Simulink Coder automatically generates a description file, which basically maps all the observable and tunable parameters of your model.
In INCA, you simply need to import this file, and with a few clicks, you can start monitoring signals and tune parameters in real-time.

And, saving the best for last, with the latest MATLAB release, Simulink Real-Time now ships with an ASAM XIL support package.
You can now freely choose the XIL test automation tool of your preference, mix and match components from different vendors, and have everything integrated with Simulink Real-Time and Speedgoat hardware.
For instance, in this video, I show you the integration with ECU Test form TraceTronic, a widespread test automation tool within the automotive industry.

To conclude, let's quickly recap the key takeaways of today.
Thanks to the unmatched integration of Speedgoat into the MATLAB and Simulink toolchain, you seamlessly transition between desktop and real-time simulation.
The customizable I/O interfaces allow you to use your real-time target machine across all development stages. We've seen examples for data acquisition, rapid controller prototyping, hardware-in-the-loop simulation, test automation and stand-alone deployment.
You can use the feature-rich Simulink test or a supported third-party tool of your choice to automate your tests.
And interacting with your test system is fully customizable, depending on if you prefer the direct Simulink interface, stand-alone desktop or web apps, or any third-party tool using the MATLAB API.


The Authors

Timo Strässle

Timo Strässle
Application Engineer

Daniel Fonte

Daniel Fonte
Head of Application Engineering

Related Content