The Mathworks Automotive Conference (MAC) 2022

The Mathworks Automotive Conference (MAC) 2022 was one-day vendor-specific conference about how Mathworks products can be/are used in the automotive sector. The set of companies represented was truly impressive. There were presentations from Lightyear, MAN, Mercedes-Benz, Volvo, Infineon, Toyota, Bosch, Continental, Real-Time Innovations, and of course the Mathworks themselves. It was a day well-spent listening to interesting talks. Here is my personal summary.

The event has taken place (presumably in Germany) since 2007! This year’s event was a hybrid event where the physical component took place in Stuttgart, Germany. I attended virtually.

Trends and Topics

The automotive general trends towards centralized compute was obviously represented here too. However, this was really a software-oriented conference, and it was more interesting to see how this affects the software architecture. 

In particular, there is a movement away from the traditional view of automotive system as a distributed system with dataflows between compute units, towards a more software-centric  service-oriented architecture.  This has quite large effects on the structure of software and how to think about software components and how to model the communication between modules.

In implementation terms, this seems to be driving towards the use of software databuses or backbones. Software modules communicate using a publish-subscribe model instead of by explicit communication from module to module.

The Data Distribution Standard (DDS, see as developed by Real-Time Innovations (RTI, seems to be the Mathworks current choice of implementation. DDS is an OMG standard. A talk from RTI showed how DDS could be integrated into Simulink using the DDS Blockset.

The Mathworks automotive pitch presented was all about model-based design and simulation. Users want to do more model-based design and simulate larger and more complex systems.

Simulink was the main tool discussed at the event, and that tool itself is going through some noteworthy changes.  First of all, the Mathworks with clear encouragement from their customers have been working on making Simulink a complete software tool. They have added features to Simulink to model the architecture of a system, as a higher-level structure compared to the typical algorithm models. According to a speaker from Mercedes Benz, this was something requested by them in order to stay in the model-based domain within a single tool instead of having to use some second tool.

The Mathworks is working hard on how Simulink models can be handled “like code”.  Running continuous integration and even deployment, using Agile methods (in the SAFe framework), using standard source control like git and applying static code analysis, devops pipelines, and running on docker containers.  They key is that all of this is done using the Simulink models themselves, not just the code generated from them. 

Talking about simulation, everyone wants to do vehicle-level simulation or vehicle+more simulation.

Polyspace analyzer was present, but it still does not feel integrated into the Simulink world. Which makes sense, as its type of analysis is done on code, and Simulink is all about avoiding code.

AUTOSAR was the most talked-about standard for how to decouple software from hardware and allow more model-driven design. But some speakers noted that Autosar does not have all the answers for how to develop service-oriented architectures. Thus, we see companies using C++ and bringing in other technologies like DDS and ROS (the Robot Operating System).

The Architecture Model layer in Simulink, from the talk “Smart Models on Smart Cars”, by Tunc Simsek from the Mathworks

Simulink as a software development environment. From the talk “Function Modeling and Validation at Mercedes-Benz: Success Factors, Roadmap, and Future Challenges”, by Christian Dziobek, Thomas Ringler, and Florian Wohlgemuth from Mercedes-Benz.

Software workflow with Simulink, from the talk “Implementing Best Practices in Your Software Factory to Improve DevOps Metrics”, by Tjorben Gross and Skanda Naglapur Ramamurthy, from the Mathworks

Using DDS to glue together classic AUTOSAR, adaptive AUTOSAR, ROS, and natively DDS components. Gives a good idea for how to think about software architecture when using DDS. From the talk “Automotive Model-Based Design with Simulink, DDS, and DDS Blockset”, by Angel Martinez Bernal, Real-Time Innovations

Connecting the in-vehicle architecture to the cloud. Note the centralized compute architecture, and the rich set of services provided in the cloud. For trucks, the connection to the cloud offers much more value to the customers, as that is all about integration of the vehicle into the overall fleet and transport management system. From the talk “The Next Level of Software Development in Commercial Vehicles”, by Stefan Teuchert, MAN Truck & Bus.

System Modeling

Observation about the simulation and modeling of complete systems:

The Mathworks has taken an interesting approach to system modeling in the product design. There are several cases where they provide generic but complete runnable models for specific use cases (including “virtual vehicles”).  The idea is to make it really easy to get going with a model for some part of the system by providing a complete starting point – even when that starting point is completely artificial and generic.

Providing a user of a tool with something to start from is a proven product tactic for modeling tools. The question is always how useful a starter/generic model actually is. I would say in general they can be useful for very focused work, but the more what is being tested cover multiple subsystems, the harder it is to produce meaningful results. On the other hand, that generic system offers a nice quick way to test component models even if no real measurements or experiments are carried out.

Quickly getting to something live is a great motivator for new users.

Another clear trend from all the customer talks during the day was that basically all of them built system models encompassing complete vehicles, and vehicles plus external services. This is called a virtual system or virtual vehicle.

The virtual vehicles are universally configurable by users. Everyone wants a system where designers and engineers can configure a custom complete vehicle model by selecting options for each component. Like selecting size of batteries, power of engines, type of suspension, etc. This kind of menu-based configurability works well in the vehicle domain since the set of components is pretty much fixed, and only the implementation of each of them differs.

Volvo example of a configurable vehicle simulator. The user selects how each component is to be implemented from a list of options.

AURIX Virtual Platform

The talk “Virtual Hardware-in-the-Loop (vHIL) for Accelerating xEV Application Software Development” by Marko Geci?, and Dineshkumar Selvaraj, from Infineon, represented the run-the-actual-code virtual platforms at the MAC.

The talk was about how they use a pre-silicon virtual platform of the Infineon AURIX TC4x automotive chip to perform “vHIL” simulation with Simulink.

The VP is the familiar AURIX VPs from Infineon. Built from an Infineon Tricore instruction-set simulator and SystemC models, using Synopsys Virtualizer as the VP tooling. Infineon has been working with Synopsys for more than 15 years on VPs. The VP runs real code, and connects to Simulink using the Synopsys Virtualizer System Interface (VSI). The model includes a rather complex timer model that slows down the simulation to a slowdown of about 150.

The system being modeled in the example was the AURIX used to control an electric motor. Simulink was used both to generate the control system code to run on the VP, as well as to model the controlled system (the plant model). The code on the VP senses the motor and provides actuator outputs over virtual hardware models, and the VP framework calls Simulink to simulate the physical world.

I guess HIL is put as “post silicon” in this image as it replaces the use of hardware connected to a hardware test system – which is a post-silicon activity. The model can clearly do both.

Overall development system.

The plant model with interfaces. Note that the plant model can be used either with real code running on the VP, or with the control algorithm in Simulink.

Electrification Notes from Lightyear

Electric vehicles were omnipresent. Pretty much all vehicle design today is for electric vehicles, be they cars or trucks.

The first keynote of the day, “How to Halve the Energy Consumption of EVs”, by Arjo van der Ham, from Lightyear, was all about how to make electric vehicles more efficient. He never mentioned any Mathworks products, and it seems this was a classic “state of industry” keynote. It was really interesting, talking about how Lightyear is trying to make useful electric cars that can be charged at least mostly using their own solar panels. He also wants to build an EV that can replace ICE cars in developing countries, which requires lowering the cost of manufacturing significantly.

A key part of enabling this vision is making EVs much more efficient.

He had some good insights into how to think about electric vehicles as a product, from the buyer perspective. Fundamentally, for almost all buyers, the key obstacles to buying an EV is range, charging time, and cost. Fancy software really does not matter, it is about the fundamentals. There are some pretty rough tradeoffs:

  • Range – adding batteries adds weight (and eventually size)
  • Charging – fast charge gives up energy density – makes the battery bigger
  • Cost – better and more batteries cost more

But this assumes that the vehicle is roughly the same from an efficiency perspective. Instead of getting stuck in this loop that ends up with our typical current EVs weighing 2000kg or more, Lightyear has looked hard at how to make the car more efficient instead of bulking up on the battery. Efficiency gives you many benefits:

  • Smaller battery can be used for same range.
  • Charging is faster in km charged over time, since less needs to be charged. Measure the time to charge a certain driving distance instead of how many watts the charger pushes.
  • Cost is lower with a smaller battery.

How to make it more efficient? Arjo showed this breakdown:

Indicating that the major sources of efficiency are:

  • Aerodynamics – Lightyear got it down by 40%.
  • Roll resistance – Got 10% from superefficient tires.
  • Mass – get the mass down by simplifying all systems. For example, Lightyear is putting motors into the wheels themselves, which they claim reduces mass.

Today, Lightyear is a few weeks ago from delivering their first vehicle, “Lightyear zero”.  Next project is “Lightyear two” driving cost towards 30k EUR. I.e., making EVs closer in price to ICE vehicle.

?One of the Mathworks presentations showed some data on the typical size of a current EV battery, just to illustrate the massiveness of a battery:

The energy carrying capacity of a battery is terrible. Going for efficiency to make it smaller makes a ton of sense.

 Hybrid Event

The hybrid version basically provided access to watch the talks. People present physically also had access to an exhibition hall and direct interaction with the staff at hand, which obviously is a lot more valuable than just listening in over the Internet. There was no chat system to allow remote interaction. The organizers claimed some 250 people attended live, with 1000 or so listening in virtually. Apparently 2000 had registered, but a fifty percent loss for an online event sounds pretty normal, unfortunately.

The event was hosted on the Mathworks own website, not on some third-party platform site. Nice professional touch. It was a true live broadcast with no prerecorded talks. This is what it looked like:

Interestingly, only one of the two afternoon tracks was broadcast. Guess that simplifies things.

During the talks, they switched between showing the speaker stage in full, slides in full, and a mixed view showing a narrow view of the speaker along with the slides like this:

Sriram Mandayam, Volvo Cars, presenting.  This is about the best capture I got – for some reason almost always when you try to capture the speaker they are blinking or gaping or looking the wrong way…

Conference pause for remote viewers.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.