Andrew Bennett, manager of engineering at MathWorks, discusses electrical and software engineering in the digital age

Please tell us about your role at MathWorks.
I lead the electrical simulation development team, focusing on Simscape. In addition to being used in the automotive industry, Simscape is used across industries to provide representations of the real world for designing, developing and testing models of physical components and systems. My team and I bring together model, control and protection systems into an overarching tool by unifying MathWorks capabilities. We then ensure they are easy to use for designing electrical systems.

What is the biggest R&D challenge you currently face?
Creating systems that serve multiple purposes is an ongoing challenge, as the models need to be the right level of detail for any given application. While one person may use Simscape to design a single circuit, another could use it to see how multiple circuits interact. To meet various customer needs, Simscape enables more complex multidomain (electrical, fluidic, mechanical, thermal) systems to be represented. These advancements are enabled by symbolic manipulation and symbolic equations that bring physics equations together in an efficient and solvable way that is useful to engineers and technologists.

What’s the general R&D and testing process at MathWorks?
In a similar way to how automotive engineers think about software design for vehicles, my team and I must think about software design from the perspective of a desktop user or a vehicle engineer who wants to use desktop software. Around 50% of my team are domain experts and 50% are software experts, so we’re trying to stand in the middle to reconcile those two areas – in a similar way to how auto makers are working as they develop software for vehicles.

Across MathWorks, we have a testing infrastructure that is effectively continuous integration; whenever we write any component, we unit test it, then scale up to system-level tests. When anyone makes any change, all of the tests have to be run for that particular component – much in the same way we’re seeing automotive companies do. We operate as a software developer using continuous integration very rigorously to make sure our software has as few defects as possible. That puts us in a great position to coach, inform and educate auto companies in how they can adopt those processes. I feel like I’m an electrical engineer who’s now also a software engineer.

In what ways do different companies use Simscape?
A lot of companies use our physical modeling tools as a proxy for the real world, such that they can simulate their control systems and protection systems in a desktop environment, to check and test that those algorithms are working correctly before they start putting the algorithms into vehicles.

Some come to MathWorks with an existing process and they realize that they can make their process much more robust and efficient by moving to MathWorks. Then there are the companies that don’t have an existing toolset. In other cases, a company might have existing code that they want to integrate. If they’ve got a motor controller or a battery controller they’ve already written, for example, they can bring that into the Simulink environment and test it against our virtual Simscape models. Or, if they want to design a new algorithm, they can do so.

How can companies cut complexity and increase efficiency when it comes to electronics engineering?
Ultimately, moving as much of the de-risking as possible earlier in the development process helps to get rid of any defects – and earlier in the process when it is cheaper to fix things. By using the physical models of electrical systems and battery systems, they’re able to fully bottom out sizing calculations, thermal calculations, electrical calculations and transient responses of these different systems as well as make and fully validate what happens when the electrical systems go wrong.

Is it worth decoupling hardware and software?
Yes. An issue that many organizations face is potentially late availability of the hardware. By having a desktop simulation model in Simscape, they can do much of the analysis early on to make sure that their systems don’t just work but that they’re robust algorithmically. Then when the actual hardware arrives, they can easily transition the algorithms through automatic code generation to do checks on the real hardware.

There is an in-between stage whereby developers will test the models on real-time hardware first. From Simscape you can automatically generate those HIL models and the software control algorithms and test them on a production ECU on a HIL rig, for instance. These are extra checks and balances as well as moving and de-risking things as much left in the process.

How would you define the current state of play in automotive software testing?
In the world we live in today, a lot of organizations are grappling with software. I don’t think it’s an automotive-specific challenge; everyone needs to improve their processes in handling the level of software engineering that’s required today to enable such complicated, highly responsive, automated systems. Using MathWorks’ tools, people can get to a solution much more quickly and get a head start to meet the challenges they may face.