Three Factors to Consider When Using Automated Tools to Accelerate Software-Defined Vehicle Development

There are three primary areas of interest among developers for software-defined vehicles using tools from MathWorks to test their work. That’s according to the company’s Global Automotive Industry Manager, Wensi Jin.

The first issue for these MathWorks customers is that their ability to collect data is outpacing their ability to consume that data, he said. “Oftentimes people don't realize that in order to use the data they actually spend far more time cleaning up the data before they can actually use the data,” Jin noted. "MathWorks is focusing on data cleanup and helping customers use its tools to extract interesting edge cases so that they can more easily address those," he said.

This is important because developers need to consider so many scenarios, reports MathWorks customer Tom Tasky, who is Vice President of FEV.io (the Intelligent Mobility, Machinery, and Software division of FEV North America Inc.). “At FEV, most engineers have a MATLAB license on their laptop,” he said. “It is a daily used tool.”

“There are a lot of good tools in the market to address this because of the need for developing test scenarios, predicting traffic scenarios, and weather conditions,” Tasky observed. “All potential scenarios that need to be addressed can be done and simulated through a variety of tools, and every OEM or company has their preference and how to how to go about this.”

Related:Apps Every Engineer Should Use

The second issue is determining the differentiating features of the software-defined vehicle under development. The industry has seemingly concluded that advanced driver assistance systems (ADAS) are one integral component, he said. But this requires new test methodologies.

“There needs to be a better way to describe the scenes and scenarios, whereas in automotive [engineering] we’re very used to the notion of speed profile,” said Jin. “It's a curve. It's a very simple curve.”

A speed profile is insufficient to be useful for ADAS systems. “We have to go into the three-dimensional space to be able to describe the scenes and scenarios, and that's one area where we have invested quite a bit in the tool family called ‘Roadrunner.’ The idea is to provide engineers a good editing environment so that they can conceive, edit, and modify static scenes and dynamic scenarios all in one environment.”

The third thing that MathWorks is hearing about from its customers is the desire to more easily employ captured real-world test data into new simulation scenarios. “Oftentimes, the engineers are saying, OK, I have this thing in the data, how do I turn this scenario that I recorded in the data into some kind of simulatable environment?

Related:AI Playing Larger Role in Automotive Simulation Systems

When engineers drive around and capture something really unusual, developers can exploit that to let the vehicle understand that event if it happens again. “[They can] mine the events from the data and the taking aspects of the data such as trajectory, such as actor behavior, and turn them into a scenario,” Jin said. “The advantage is that once you have such generic scenario in an editable format is that you can spin off new scenarios, new edge cases that are similar, but maybe slightly different.”

Combining the real and virtual worlds is crucial, according to Tasky. “We manually still drive vehicles around, because you still want these real-world scenarios and data as input that you can then replay to test your algorithms,” he said. “I think that is a critical piece as well.”

Tasky cites an example of an edge case that was captured through physical testing that is unlikely to have been imagined for simulated testing. The test car encountered a flatbed truck on the side of the road loading a disabled vehicle with its bed tilted upward, revealing the surface to the test car’s sensors. “The flatbed truck had those similar lane markings on its flatbed as it was trying to pick up a car and one of the [test cars] captured that as thinking that was a lane,” he recalled. Seeing this in the real world provided the chance for developers to ensure that their ADAS system doesn’t mistake a tilted flatbed with lane markings on the bed for a road where the car can drive.

Related:Verifying ECUs With Hardware-in-the-Loop Testing

Such physical testing can slow development, however. “These are all time-consuming processes, but critical steps because you can only simulate and come up with enough scenarios,” Tasky observed. “Then we're getting real data and know that you are using the real-world sensors and test environments effectively to couple that with. Maybe over time, you could then still further limit the real-world testing as you then further prove the fidelity of the models and simulation that you're working on.”