In this week’s Fish Fry podcast, we’re casting our line into one of the most transformative shifts happening in the automotive industry today: the rise of software-defined systems! Nitish Rao from MathWorks and I take a closer look at which vehicle functions are best handled by AI-driven systems, and which still depend on the reliability of traditional control software and how virtual ECUs and digital twins enable simulation and validation before real hardware. We also discuss a question many engineers are asking: can software and AI actually reduce hardware costs?
Links for March 13, 2026
MATLAB and Simulink for Automotive
Software Architectures with Simulink and System Composer
Click here to check out the Fish Fry Archive.
Click here to subscribe to Fish Fry via Podbean
Click here to get the Fish Fry RSS Feed
Click here to subscribe to Fish Fry via Apple Podcasts
Click here to subscribe to Fish Fry via Spotify
Amelia’s Weekly Fish Fry – Episode 673
Release Date: March 6, 2026
Host: Amelia Dalton
Guest: Nitish Rao, MathWorks
Transcript
Amelia Dalton:
Hello there, everyone. Welcome to episode number 673 of this electronic engineering podcast called Amelia’s Weekly Fish Fry, brought to you by EEJournal.com and written, produced, and hosted by yours truly, Amelia Dalton.
This week, my friends, we’re talking all about software-defined systems in automotive design. My guest is Nitish Rao from MathWorks, and we’re taking a closer look at the vehicle functions that are best handled by AI-driven systems and which still depend on the reliability of traditional control software. We’ll also discuss how virtual ECUs and digital twins enable simulation and validation before real hardware exists.
And we’ll tackle a question many engineers are asking:
Can software and AI actually reduce hardware costs?
So without further ado, please welcome Nitish to Fish Fry.
Automotive Software Transformation
Amelia Dalton:
Hi Nitish, thank you so much for joining me.
Nitish Rao:
Hey Amelia, nice to be here.
Amelia Dalton:
Let’s talk about automotive software. Nitish, what technical and business factors are driving changes in automotive software in particular?
Nitish Rao:
Absolutely. Automotive software—and the industry itself—is undergoing a major transformation.
As consumers, we expect our cars to be safer and to provide more features: automated driving capabilities, seamless connectivity with our digital lives such as music streaming services, and multiple powertrain options for different consumer groups.
To support this growing feature set, the industry is moving away from dozens of siloed ECUs toward a smaller number of high-performance compute platforms that run sophisticated software stacks. This shift enables over-the-air updates and adds new capabilities in driver assistance and connectivity. As a result, a vehicle can actually improve while it sits in your garage—becoming better than the day you bought it.
On the business side, software has become a major differentiator. Automakers are increasingly judged on questions like:
-
Does the car support CarPlay?
-
Can it warn me about potential collisions?
-
What software-enabled features does it offer?
Mechanical refinement alone is no longer enough.
Additionally, automakers are exploring subscription models to generate ongoing revenue from software features. All of these changes require automotive software to be rewritten to support the industry’s broader transformation.
AI vs Traditional Control Software
Amelia Dalton:
What automotive functions do you think are best handled by AI, and which still rely on traditional control software?
Nitish Rao:
Traditional control systems remain essential for deterministic, safety-critical systems—things like braking, steering control, or airbag deployment. These systems will continue to be built using classical approaches like PID controllers and model predictive control.
AI, on the other hand, is much better suited to environments that are probabilistic or messy.
For example, perception software that detects objects using cameras or other sensors is an area where AI really shines.
A simple real-world example is automatic emergency braking, a regulation that is being adopted by many governments around the world. In this system, the vehicle uses sensors—such as cameras or radar—to detect objects in front of the car and warn the driver about a potential collision.
AI is used to classify objects detected by the sensors. But once the AI determines that an object is dangerously close, traditional control systems must calculate:
-
braking distance
-
braking force
-
or even an alternative trajectory to avoid a collision.
This combination plays to the strengths of platforms like Simulink, which allow engineers to integrate both worlds. You can prototype AI-driven perception systems while still building rock-solid deterministic controllers—all within one environment.
Can AI Reduce Hardware Costs?
Amelia Dalton:
How can software or AI reduce vehicle hardware costs rather than just adding features?
Nitish Rao:
People often think of software as something that adds cost, but it can actually reduce the overall system cost by simplifying or replacing hardware.
For example, software-defined architectures allow automakers to consolidate ECUs. This reduces wiring harness complexity, lowers bill-of-materials costs, decreases vehicle weight, and improves efficiency.
AI-based perception can also allow vehicles to work with cheaper sensor hardware. In some cases, AI models can replace physical sensors altogether. In electric vehicles, software can optimize motor design or enable predictive maintenance, reducing the need to over-engineer mechanical components.
So there are several ways software and AI can help lower vehicle costs, not just add features.
Tools like MATLAB allow engineers to prototype algorithms and identify opportunities to downsize or consolidate hardware early in the design cycle.
Why Hardware Testing Is a Bottleneck
Amelia Dalton:
Why is testing vehicle software on physical hardware becoming a bottleneck for frequent updates?
Nitish Rao:
In the past, vehicle development cycles were much longer, and testing on physical hardware was built into the schedule. Software was typically frozen months before a vehicle entered what the industry calls series production.
But today, if software is updated every quarter—or even every month—hardware becomes a bottleneck.
Physical testing introduces friction:
-
limited hardware availability
-
long setup times
-
slow iteration cycles.
ECUs have finite I/O channels, test benches must be scheduled, and hardware-in-the-loop setups simply can’t keep pace with modern software release cycles.
Meanwhile, regulatory and safety requirements demand extensive test coverage, which is difficult to achieve with hardware-only testing.
This mismatch between fast software evolution and slower hardware cycles slows down development and is one of the biggest barriers to continuous updates across large vehicle fleets.
Virtual ECUs and Digital Twins
Amelia Dalton:
What advantages do virtual ECUs or digital twins provide compared with hardware testing?
Nitish Rao:
Virtual ECUs and digital twins help break that bottleneck by allowing engineers to run large-scale simulations without physical hardware.
Digital twins allow engineers to simulate durability, performance, and operational conditions long before a physical prototype exists.
Because virtual ECUs behave like real control units, thousands of tests can run in parallel in the cloud. Engineers can catch issues earlier, reproduce bugs deterministically, and integrate AI components into high-fidelity vehicle models.
MathWorks tools are a big enabler here. Simulink helps engineers configure virtual vehicles, and virtual ECUs can then be integrated into the simulation to complete the digital twin.
The Software Complexity Gap
Amelia Dalton:
Why do you think there’s a gap between software complexity and engineering coding expertise?
Nitish Rao:
As vehicles evolve into something like rolling supercomputers, the amount of software—and its complexity—has grown dramatically.
Engineers now need to integrate:
-
AI models
-
cybersecurity layers
-
connectivity stacks
-
real-time control systems
-
high-performance compute accelerators.
However, many automotive engineers come from mechanical or electrical engineering backgrounds, not large-scale software architecture.
This creates a steep learning curve and potential bottlenecks, especially when systems must remain safe, secure, and maintainable for decades.
That’s where model-based design becomes valuable. Engineers can design systems at a higher level of abstraction—starting with models—and then generate code automatically. This reduces the gap between domain experts and software engineers.
Meeting Automotive Safety Standards
Amelia Dalton:
With model-based design, what does it take to meet automotive safety standards beyond simply proving that the software works?
Nitish Rao:
Meeting automotive safety standards such as ISO 26262 requires much more than verifying that the software runs correctly.
It involves:
-
functional safety analysis
-
traceability from requirements to implementation
-
deterministic behavior
-
fault-injection testing
-
tool qualification
-
model verification.
AI adds additional complexity because AI systems are probabilistic. Safety frameworks now require explainability, coverage analysis of training data, and proof that potential failure modes are contained.
Model-based workflows in MATLAB and Simulink help generate traceability, automate consistency checks, and support compliance through qualified code-generation pipelines.
Scaling AI Vehicles to Production
Amelia Dalton:
What is the most critical challenge carmakers face in delivering AI-driven vehicles at scale?
Nitish Rao:
The biggest challenge is scaling from prototypes to production.
Building a single AI-powered demo vehicle is relatively easy. But deploying AI safely and reliably across millions of vehicles is far more difficult.
There are three major hurdles:
-
Data and model lifecycle management – AI models require continuous updates, validation, and retraining.
-
Safety integration – probabilistic AI must work alongside deterministic safety architectures.
-
Industrialization – integrating cloud-heavy AI pipelines with automotive-grade embedded systems.
For example, the industry has reported delays in deploying Level 3 and Level 4 autonomy because of reliability and regulatory challenges.
This is why large-scale simulation and model-based design environments—like those supported by MathWorks—are becoming essential.
Off-the-Cuff Question
Amelia Dalton:
All right, Nitish, it’s time for your off-the-cuff question.
If you could have one meal right now—anywhere in the world—what would it be?
Nitish Rao:
I enjoy riding motorcycles, and I’ve traveled to the northern regions of Thailand. If I could go anywhere for a meal right now, I’d get khao soi. It’s crispy noodles sitting on top of soft noodles with a coconut milk curry sauce. The textures and flavors are amazing.
Amelia Dalton:
That sounds absolutely wonderful.
Nitish, this was super cool. Thank you so much for joining me.
Nitish Rao:
Thank you, Amelia. This was fun.
Closing
Amelia Dalton:
If you’d like more information about this topic, I’ve included links below the player on this week’s Fish Fry page on EEJournal.com and in the description for this week’s YouTube episode.
Well folks, that’s all I have for this week’s Fish Fry—but I’ve got some exciting episodes on the horizon, including:
-
a discussion with Ferric CEO Dr. Noah Sturcken about challenges facing high-performance processor applications and Ferric’s IVR technology
-
a conversation with Joe Adiletta, CEO at Volexion, about battery manufacturing and advanced materials
-
and an interview with Sandra Rivera from VSORA about the role of inference in AI systems and what sets this French AI accelerator startup apart.
Hey—have you checked out EEJournal on social media yet?
You can find us at:
-
facebook.com/eejournal
-
LinkedIn
-
BlueSky
-
Mastodon
And of course, we also have a YouTube channel: youtube.com/eejournal.
Leave a Reply
You must be logged in to post a comment.