Video Transcript
Hello everyone, and thanks for joining this webinar!My name is Timo, I'm an Application Engineer at Speedgoat with a focus in the automotive domain.
Today, we are going to talk about how Speedgoat enables innovation for automotive hardware-in-the-loop testing and control design.
Let's start with a great example from the players in the field, which covers many of the topics we want to address today.
A brave team of researchers at the technical university of Munich is developing fully autonomous, all-electric racecars with breathtaking performance.
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.
The cars are powered by four electric motors, requiring precise control to tame the combined force of over 500 horsepower.
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 race track 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.
With this hardware-in-the-loop or HIL setup, the team could evaluate design iterations quickly, and test edge cases, emergency procedures, and hardware failures in a safe environment.
When they finally took the car to the race track for in-vehicle testing, they could focus on fine-tuning and verification.
With Speedgoat hardware and the model-based design workflow, the team was able to win multiple competitions, like the human + machine challenge in Berlin, and the fully autonomous racecar already achieves lap times on the level of an amateur human driver.
And by the way, you can access the complete software stack by TU Munich in the form of a reference example on speedgoat.com, as well as a whitepaper on sensor fusion and motion control for autonomous racing cars.
The advancements by the TUM racing team push the limits of three big market trends we will focus on today.
Then I'll introduce the Speedgoat and MathWorks solution to address the challenges they bring.
We'll see how hardware-in-the-loop testing and rapid control prototyping can accelerate your development, and we'll look at some specific application examples for each area and market trend.
In the end, we will have a live Q&A session.
So, let's get started.
The first market trend is towards more hardware in the loop testing with digital twins.
You can accelerate development cycles and fix design flaws earlier by creating a digital twin of your powertrain for virtual testing.
This will allow you to start testing earlier and more flexibly, with less logistics involved.
And you can fully automate HIL testing for extensive and long-term test campaigns.
Second, there is an increasing trend of Electrification.
With the need to reduce emissions and transition to sustainable energy sources, electric vehicles are becoming more and more popular.
Electric motors also provide great efficiency and performance.
This comes with the need to develop and integrate new technologies such as electric powertrains and battery management systems.
The third and final topic we will focus on is the trend towards automated driving.
New sensing and processing capabilities can make driving safer, improve the driver and passenger comfort and the traffic flow.
But there are strict certification requirements to be met, which further increases the need for extensive testing and verification.
Of course, new technologies always come with a lot of new challenges.
These include the integration of new technologies into existing workflows, modelling complex systems for simulation, interfacing the simulation with real hardware, and meeting all the safety and reliability requirements.
So, in summary, you want a unified and intuitive solution, which allows you to start quickly and reuse your investments throughout development.
Together, Speedgoat and MathWorks provide such a unified solution, allowing you to address all these challenges using one integrated toolchain.
Our real-time simulation and testing platform simplifies your workflow and lets you design and test better controllers and plant models faster.
You can innovate and you are not constrained by embedded testing environments or with the hassles of integrating solutions.
Benefit from a plug-and-play real-time solution that shields you from interoperability issues.
Experience the unity of simulation and testing with real-time target hardware, all directly from MATLAB and Simulink.
The seamlessly integrated solution is composed of two main components.
The first one, is Simulink Real-Time, the solution for real-time test and simulation from within MATLAB and Simulink.
It comes with several host capabilities that allow you to easily create, control and monitor your real-time applications, and it serves as your real-time operating system.
The second component is powerful and scalable Speedgoat real-time target computer hardware, equipped with I/O.
The real-time application created from your Simulink model runs on it together with the Simulink real-time operating system.
And how can your development process benefit from real-time simulation and testing?
You typically want to get from an early design idea to deployment in production.
As a simple example, let's say you design a cruise controller for your new electric powertrain.
If you design the controller in Simulink, you easily perform desktop simulation,
But for the best results, you should also test it against the real plant. And you can do so with real-time testing for RCP, short for rapid controller prototyping.
From your Simulink model, you generate a real-time application, and deploy it to a Speedgoat target machine.
Our automotive I/O modules let you connect the target machine to the real plant, such as a prototype car or motors, to test and tune your algorithm.
Once you have tuned and verified your controls, you could use Embedded Coder to generate the embedded code for your ECU from the same model.
To test the ECU, you can then perform hardware-in-the-loop testing, using the real-time target machine again.
You run a real-time digital twin model of your vehicle and test the ECU against the virtual plant.
Speedgoat offers a wide range of real-time target computers.
Benefit from the greatest power and flexibility with the Performance machine. It allows installing up to 50 I/O modules for the highest flexibility, ideal for complex tasks like multi-cell battery emulation, power hardware-in-the-loop or high-fidelity powertrain simulation.
The Performance machines are designed also for rack-mounting.
The Mobile, Baseline and Unit machines are ruggedized and therefore ideal for in-vehicle testing.
Depending on your compute tasks and I/O requirements, you will find an excellent trade-off between compact form factor, power, and flexibility, while allowing for modular I/O expansion.
The installed I/O modules are configured directly in your Simulink model, using the Speedgoat I/O Blockset, ensuring a seamless workflow.
And no matter whether you are prototyping control strategies or testing controllers against your digital twins, connectivity shouldn't be a hurdle for you.
We are supporting key protocols from automotive and other industries., such as CAN and FlexRay, serial protocols, PWM generation and capture, and battery cell emulation.
More than 200 I/O modules are available and ensure that your workflows remain un-interrupted.
Now, let's look at the application side of things. In the next 2 chapters, we'll cover hardware-in-the-loop testing and rapid controller prototyping.
I explained with this illustration that RCP means testing your controls in real-time against the real plant, and HIL means testing your embedded controller against a real-time plant model.
But it's not always just about RCP or HIL. Today's systems are way more diverse.
So, we'll touch base on use-cases such as ECU bypassing and calibration, autotuning your control parameters, ss well as Power-hardware-in-the-loop, modelling and simulation of electric, hybrid or fuel-cell powertrains, and restbus simulation.
Let's focus on the HIL workflows first.
Frontloading verification and validation tasks commonly is the main motivation for HIL testing.
It may be that the hardware prototype is not available, or you gradually integrate components.
You want to resolve design flaws and test edge cases in a safe environment.
What do you need for HIL Testing?
Certainly, a platform that runs your plant in a deterministic manner while being connected to sensor and actuators, that allows for plug & play interfacing, and test automation.
Ultimately, this will help you deliver embedded software faster and with lower risk.
So how could such a HIL setup look for your application?
Depending on your requirements, setups can range from a single target machine to complete HIL racks.
Let's look at an example.
There are two components involved in HIL testing:
First, your controller under test. This includes both the production hardware and the embedded software.
And second, a HIL test system.
The HIL system is composed of a real-time simulator that runs a digital twin deterministically, together with I/O modules that ensure low-latency data acquisition, signal conditioning, and communication with the controller under test.
The host computer runs dedicated application software that supports you on the setup and operation of the real-time simulator.
Depending on the size of your group, and how you organize development of embedded software, the HIL system setup and controller HIL testing can be done by the same or different teams.
Let's assume our embedded system group is segmented into three:
The HIL systems engineers, focusing on assembling and setting up new HIL test systems. The embedded software validation team, in charge of running embedded SW test campaigns. And the embedded software development team, tasked to develop and revise the embedded software.
So, the question is how are we enabling these teams to succeed in their specific tasks?
The systems engineers have previously built a HIL test system based on the Speedgoat Performance machine.
They are now challenged to specify a new, much more complex HIL test system, which is required to integrate high-power actuators and electronic loads and sources.
Implementing such an HIL system is time-consuming and requires specific expertise.
With that in mind, the team decided to rely on Speedgoat's know-how to provide them with a modular, rack-mounted HIL solution customized to their needs.
The final solution looked as follows:
Two rack-mounted performance real-time target machines, enabling distributed and synchronized simulation across multiple chassis.
This setup fully integrates all power electronics components, the required signal routing and conditioning modules, as well as breakout panels and the cabling harness.
For the systems engineers, this is a true plug-and-play solution.
With hardware hurdles off the table, the team was able to focus on the design of the digital twin and even introduced some innovations.
For instance, model parameters are now automatically fine-tuned to fit measured data.
Connectivity with the controller was also done very quickly with simple drag and drop of Speedgoat driver blocks.
Using Simulink real-time, the model ran on the Speedgoat machine with a simple click, and the team could verify correctness of all interfaces right from Simulink.
The HIL system was instrumented with MATLAB's built-in App Designer. User interface controls directly connect with the real-time application, allowing HIL system operation to be Simulink-independent.
In parallel, the software validation team has been creating scripts to batch and optimize test workflows.
Part of the team has also been using Simulink Test, which has shown to be a great asset.
For instance, most of the desktop simulation tests were reused in the real-time runs.
Real-time test campaigns were triggered with a few clicks, and the assertion of results was fast and easy, using inbuilt visualization tools.
Besides, detailed test reports could be generated automatically. This greatly simplified communication with the software development team and helped further expediting software revision work.
So, you've seen the customizable hardware, but what about the software? How do you create a complex model like a virtual vehicle for HIL testing?
Well, MathWorks and Speedgoat offer various pre-built reference examples to get you started quickly.
The foundation for high-fidelity vehicle models is provided by the Powertrain Blockset and Vehicle Dynamics Blockset.
With Simscape, you can also add multi-domain physical components to your model, like electrical and thermal subsystems.
And with the Speedgoat I/O Blockset, you configure all the I/O interfaces directly in Simulink, to easily send and receive signals.
But we know you don't always need a complete virtual vehicle model. A key workflow in HIL testing is restbus simulation.
It essentially means that parts of one or multiple vehicle buses are simulated, to facilitate verification and validation of the ECU under test.
Speedgoat offers a complete solution for this workflow, based on our automotive bus simulation I/O module.
This configurable I/O module covers all relevant automotive buses, such as:
CAN, CAN-FD, LIN, FlexRay, SENT, and Automotive Ethernet.
And it's fully compliant with Autosar requirements.
This module comes with a fully-featured, Simulink integrated user interface.
With just a few clicks, you can create complex static restbus configurations, including:
Multi-channel bus configuration, automatic generation of bus frame and PDU signals, checksums, and alive counters.
Besides, the configuration tool supports all mainstay automotive bus matrices, from legacy DBC to AUTOSAR xml files.
Performing dynamic bus simulation in Simulink is also no longer a problem. The Simulink blockset supports with all kinds of dynamic restbus operations.
For instance, you can quickly manipulate signals, PDUs or complete frames, control execution of the static restbus application, or even switch on and off complete ECUs.
Now, let's go back to creation of your digital twin vehicle.
Powertrain Blockset gives you quick access to conventional and electrified powertrain models.
The in-built libraries provide easy-to-use Simulink blocks, including batteries, electric drives, and electric motor controllers.
Many well documented and ready-to-use reference examples get you started quickly.
These are Simulink-based very fast-running models that you can fully customize and instrument and that are ready for HIL deployment and closed loop simulation with your controls.
The same model can be used to support you with different tasks, like tuning motor and brake controls, designing capabilities such as torque vectoring control, or developing and testing battery management systems.
Let me quickly show you how to access the built-in examples. In the MATLAB documentation, here for the Powertrain Blockset, you just click on Examples to see the list of all the pre-built Simulink projects.
I'll just go ahead and open the electric vehicle reference example here.
Click the button, and a few seconds later, the Simulink model opens for you to freely explore, run simulations, and customize it to your needs.
With detailed models for all your electric components, real-time testing is also a powerful tool supporting the development of battery management systems or fuel cell controls.
There's a couple of reasons why you might not want to test your early prototype algorithm on real power systems.
For example, testing a complete charge and discharge cycle on a real battery pack can take many hours.
Reproducing design issues and fault conditions can be difficult and raise serious safety concerns.
And if the process is lengthy, you wouldn't want to repeat it for every software revision.
Allow me to mention Speedgoat's solution for development of Battery Management Systems. It enables modeling and emulating batteries down to cell level.
You can stack several of these modules to build a HIL simulator of a full battery pack, including fault insertion and temperature simulation at cell level.
Simulink and Simscape provide a wide range of example models for different battery types.
For each battery cell, you can also have optional modules to emulate temperature sensors for each cell and to test fault conditions like broken wire and short circuit.
Let's take a quick lock at a test model which allows us to simulate battery cells and generate fault scenarios.
We have a BMS under test and connect it to an emulated battery pack using the battery emulation I/O module.
To simulate a fault, we added a switch which allows us to short two cells in simulation, without physical consequences.
Additionally, we use a slider to set the charge or discharge current.
To perform diagnostics on cell level, we measure the voltage between two cell terminals.
The measured cell voltage values are sent to the I/O module, which converts the numerical values into voltage outputs, each relating to an individual battery cell.
The BMS controller performs diagnostics on cell voltages and detects overvoltage or undervoltage faults and short circuits between two terminals.
When we inject a short circuit fault, we can immediately notice the red warning light.
Let's look at the results for the whole experiment in the simulation data inspector. We can notice small changes in cell voltages due to the change in current. And one of the cell voltages dropped significantly as we triggered the fault.
Using this data, we can optimize the conditions based on which a fault is detected, to ensure safe battery management.
Our customer Leclanché uses Speedgoat products to develop lithium-ion battery packs for autonomous vehicles.
They were struggling to test their BMS in realistic conditions without connecting actual battery packs, leading to late bug discovery and a lot of manual testing.
With the Speedgoat HIL test bench, they can now emulate battery cells to test CAN communication and validate the BMS and state of charge estimation algorithms.
They successfully cut testing time in half, and at the same time increased test coverage, leading to faster development and early bug detection.
To model electric and other physical components, you can do physical modelling with Simscape.
It allows you to arrange fundamental components into a schematic which integrates with your Simulink model and fully supports code generation.
With physical modelling, you get the highest-fidelity simulations for things like batteries, fuel cells, thermal cooling systems and more.
And again, you don't have to start from scratch.
For automotive models, the Simscape Vehicle Templates provide a great starting point.
This ready-to-use reference example enables you to easily explore model architectures for conventional, hybrid, battery electric, and fuel cell vehicles with Simscape-based subsystems.
The user interface allows you to easily switch between different vehicle configurations and find the right model fidelity for your tasks.
Perhaps you are working on battery system design, and you would like to analyze the thermal behavior with an activate colling system.
All Simscape vehicle template configurations are compatible with real-time execution using Speedgoat hardware and Simulink Real-Time.
Adding hardware connectivity and preparing the model for real-time simulation only takes a few clicks.
With the help of Simulink Real-Time you can perform real-time runs of full vehicle models in seconds, and start evaluating and comparing new system designs, test hardware-in-the-loop, size components, and collect data for detailed real-time analyses​.
You can directly use these models as high-fidelity virtual vehicles, to test early prototypes or embedded controllers.
Now, the more high-fidelity components you integrate, the more computational power you need to run your model.
To achieve your sample time requirements, you might need to run your model distributed across multiple systems.
Speedgoat target machines can be interconnected and fully synchronized for distributed simulation.
You can leverage shared memory to enables ultra-low latency data exchange, and you can use interrupt signals or clock synchronization to trigger synchronous execution.
The flexible solution allows you to scale the systems to your needs at any time.
The technology enables you also to build real-time driver-in-the-loop simulators, which is great when it comes to testing the human interaction with your models.
Manual controls allow you to assess things like vehicle handling, the functioning of the connected hardware, and is especially useful for testing the interaction with assistance systems, such as control handover between human and AI.
In the video below, you can see a MathWorks Engineer controlling the simulated car in our Driver-in-the-Loop reference example.
Direct control of the vehicle is achieved by simply replacing the pre-defined driving maneuvers with a steering wheel interface for a human driver.
The vehicle state is streamed to the host computer for live visualization.
Our driver-in-the-loop reference example can be downloaded from the Speedgoat webpage.
And there is also a more in-depth webinar from MathWorks on building real-time driver in the loop simulators with Speedgoat hardware.
And this concludes the section on hardware-in-the-loop testing. Next, let's discuss rapid controller prototyping.
As mentioned before, some use-cases here are for example ECU bypassing or calibration, and autotuning of your control parameters.
Your workflows may deviate slightly, but we think you would agree on the following three main motivations for real-time based controller prototyping.
Test early to prove that your algorithms work in real-world dynamics.
You may find better trade-offs and tweak performance.
I've already mentioned the unified workflow combined with flexible and powerful hardware.
This unique combination allows you to worry less when testing.
Ultimately, you can be more innovative, expose design flaws earlier, and shorten time to market.
But we know, you rarely design controllers independently and from scratch. Typically, you take into account already existing infrastructure.
You might want to rework only specific components of an already existing ECU?
Or perhaps you are in the middle of a test and integration campaign, and you need to rapidly modify parts of the embedded design, while avoiding the lengthy embedded software iteration process.
In this case, you can utilize Speedgoat for bypass rapid prototyping.
Unlike in fullpass prototyping, where you would virtualize your full controller, using the Speedgoat target as a prototype controller, with bypassing you only run specific parts of the software on target hardware, for instance a modified design that you created in Simulink.
Deterministic real-time behavior between bypassed and embedded components is achieved by establishing a bypass service with hooks and data links using the universal XCP protocol.
This enables the ECU to send input data to the Speedgoat bypass unit, through a data acquisition link, and the other way, signals are sent to the ECU through a signal injection link.
In early design stages, bypassing allows you to rapidly prototype and test new function designs, without being limited by the embedded hardware.
So, you can implement development stages with higher confidence and guarantee that your design choices will fit the embedded environment.
During integration, bypassing allows you to rapidly introduce and test late design changes while minimizing the effort of software revisions. In summary, bypassing helps de-risking and speeding-up development stages.
The XCP protocol is also commonly used in the automotive industry for ECU measurement and calibration.
With Speedgoat prototyping solutions you can perform measurement and calibration of early controls directly with your real-time target machine.
You can do this either directly from within Simulink, as shown already, or by using a third-party tool of your preference, such as CANape by Vector or INCA by ETAS.
Let's have a look how things actually play along inside Simulink for bypassing and calibration.
Let's start with a measurement and calibration use case, by using a simple model of a damped oscillator.
This model contains several tuning parameters, including 1D and 2D lookup tables that invert and rescale signals.
Our goal consists in calibrating these parameters using the INCA tool, instead of Simulink Real-Time.
When we build the model, Simulink Coder automatically generates a description file, known as ASAP2 or A2L file.
This file basically maps all observable and tunable parameters of your model.
In INCA, you simply need to import the A2L file and with a few clicks, you can start monitoring signals and tune model parameters in real-time.
Let us now switch to the bypass use case.
Remember, in this case, the Speedgoat no longer acts as a slave device.
Instead, it plays the role of a master device that actively reads and overrides signals of the ECU under test.
Speedgoat and Simulink Real-Time enable this capability through dedicated blocksets that allow you running XCP master over CAN and UDP transport layers.
We start by defining the transport layer, which in our case is going to be UDP.
Since we are now acting as XCP master, we will import the A2L file from the ECU.
You can then start configuring the data acquisition links to read data from the ECU and stimuli links, to override signals on the ECU.
In our example, we will run stimulation for two ECU sensor signals.
With our unified workflow, we can enable bypassing directly from Simulink, using a simple switch, and modify values written to the ECU during runtime of the application, using a slider widget.
During the HIL section, I mentioned how you can test your controller against a simulated plant model.
But to identify the real motor parameters and fine-tune your controller, you also need to interface with the real electric motor.
The complete workflow of RCP and HIL for electric motor control is illustrated in the Speedgoat Electric Motor Control reference example.
It comes with all the hardware needed for testing; a Baseline real-time target machine with a Simulink-programmable FPGA, a 3-phase inverter, and a brushless DC motor.
With this simple setup, we can replicate the exact same workflow you would use to tune your electric powertrain controls.
For rapid control prototyping, directly connect your real time application to your electric motor drive with flexible PWM and other digital outputs.
You can read back position, speed, voltage, current and temperature signals.
The reference example comes with fully documented workflow examples for designing, testing, and tuning closed-loop control.
Let's quickly check out how you can control a real-time application directly from within Simulink.
Connecting to the target and starting the application just takes a few clicks.
When the application is running in external mode, we can change parameters, and the changes will take effect immediately.
For example, let's switch the control inputs to manual user control.
With Dashboard controls inside Simulink, we can now set the motor speed and also view the logged data.
The same functionality can also be achieved with stand-alone apps built with MATLAB App Designer. These allow you to interface with the real-time application without even opening Simulink.
You can download this reference example in the Knowledge Center section of our homepage.
In a customer project, we used the same hardware and coupled two of the electric motors together.
This allows for testing and simulation of disturbances.
For example, you can apply velocity control to your driving motor, and simulate a variable resistance, like wind or road inclination, with the other motor.
This enables you to evaluate the performance of your controller under real-world conditions.
So, we covered low-level control of the actuators, but what about high-level decision making? This leads us into the area of assisted and automated driving.
Rapid control prototyping is also a crucial tool here.
From a 3D visualization, you can generate artificial sensor data, or you can inject previously recorded data to test your controller in real-time simulation.
This enables you to test the robustness of assistance systems during development.
Let's look at some examples here as well.
Our reference example for real-time lane keeping assistance shows the strength of model predictive motion control.
To enable closed-loop control, camera images are generated from simulation, and injected into the system for real-time lane detection.
This example uses two real-time target machines interconnected via CAN and UDP.
The Performance machine runs the lane detection and vehicle dynamics, while a Baseline handles the MPC controller.
The 3D rendering is done on the host computer.
Here you can see this example running in real-time.
Model predictive control proves very powerful in automotive applications.
It uses a vehicle dynamics model to predict the vehicle behavior and ensure smooth and predictive driving.
It also allows you to enforce constraints like maximum steering angle.
And by trading off the prediction horizon and complexity of the dynamics, it can be optimized for real-time performance.
MathWorks' Model Predictive Control Toolbox natively supports code generation for real-time execution.
With MPC Toolbox, you can design controllers from scratch, or use available library blocks.
Here you can easily define the vehicle parameters for prediction, as well as the control parameters, like constraints and the prediction and control horizon.
For the highest performance requirements, MPC Toolbox and Speedgoat also integrate with the FORCESPRO solver by Embotech.
They provide a highly efficient solver for optimization problems, with a special focus on certifiable real-time performance.
On the right, you can see an impressive demonstration of the FORCESPRO solver used for motion planning, in a scenario where the car has to quickly change its trajectory when an obstacle is detected. The test drive was performed in a collaboration between Embotech and Thyssenkrupp.
Perhaps, you would like to inject sensor data - either simulated or logged physical signals - into lidar, radar and camera-based sensors, or validate perception functions.
This is not a problem. You can combine Simulink and Speedgoat HIL systems to generate raw sensor data or object lists directly from synthetic scenarios.
And then stream this data over sensor and controller specific interfaces, for instance using vision and Ethernet-based I/O modules.
Going back to our lane keeping example, we can also address the limitation of vision processing running on the CPU.
Detecting lane markings from high resolution camera is critical, but computationally very intensive.
To meet real-time performance at the camera rate of 60 frames per second, we need hardware acceleration.
FPGAs provide deterministic, massive parallel computational power with very low latencies, and Speedgoat provides direct vision interfaces to the FPGA module.
Using our vision I/O module, we have prototyped an FPGA implementation of the lane detection algorithm.
At the right frequency, this allows us to process the full pixels stream from a 1080p 60fps camera.
Vision HDL Toolbox enables you to implement FPGA vision algorithms in Simulink, and with HDL Coder, you can then automatically generate HDL code from the model.
On speedgoat.com, you can find more information and access our reference example for lane detection on FPGAs.
To verify this FPGA algorithm, we integrated it into our driver-in-the-loop setup together with MPC lane following and added a functionality to switch between manual controls and the lane following controller.
An indicator shows the availability of the lane keeping system, based on the confidence in the lane detection, and curvature of the road.
This nicely illustrates how you can test assistance systems in a safe environment.
And this concludes the section on rapid controller prototyping.
Before we start with the Q&A session, let me give you a brief recap of the powerful workflows we saw today.
With the Speedgoat I/O Blockset, you quickly define your I/O interfaces directly in Simulink.
With automatic code generation, you easily turn your Simulink model into a real-time application.
You deploy and run the model in a few clicks, and interface with the simulation and tune parameters at runtime.
And you can perform extensive data logging, analysis, and visualization easily with native MATLAB and Simulink tools.
Speedgoat hardware is the recommended solution by MathWorks for real-time simulation.
Our close collaboration ensures that all the latest features are tried and tested with Speedgoat hardware upon release.
This means you don't need to switch to third-party tools during your workflows.
The support teams from MathWorks and Speedgoat also work together closely to provide a seamless experience tailored to your needs.
To conclude, I would like to emphasize our three key takeaways:
First, you can accelerate testing workflows and start testing earlier, with real-time simulation for hardware-in-the-loop testing and rapid control prototyping.
Second, integrate production hardware components via I/O interfaces for tuning and verification and validation.
And third, automate testing and reuse your models throughout development, to accelerate time to market.
Ultimately, this will allow you to tackle the challenges posed by the three megatrends we saw, HIL testing, electrification and the road towards automated driving.
Thank you very much for your attention. I will now hand back to our host, and will be back shortly to answer your questions.