2388812_en-US

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2388812_en-US

2388812_en-US

Hello World with the Model-Based Design Toolbox — Model. Generate. Drive.
1

Every great build starts with "Hello World"


Every engineer remembers their first “Hello World” — that small, satisfying moment when an idea typed on a screen suddenly comes to life on a real machine. This series is a take on that same feeling, only this time the “machine” is a car. It’s a demonstrator that looks and behaves like a real vehicle, showcasing the combined use of tools from both the NXP and MathWorks ecosystems. This demo has been showcased at several events, including most recently at the MathWorks booth during Embedded World 2026 and MathWorks Automotive Conference, where the demo video that accompanies this series was filmed. Think of these articles as a guided tour through how the whole thing comes together, piece by piece.

▶ Watch the demo in action — presented at the MathWorks booth, Embedded World 2026

3

From a model on a laptop to silicon on the bench


How does a car end up running on NXP silicon, starting from a model on a laptop? That’s where the NXP Model-Based Design Toolbox (MBDT) comes in. It acts as the bridge between the MathWorks ecosystem — Simulink and MATLAB — and NXP’s processors and embedded tools. An application is designed and modeled in Simulink, MBDT generates optimized code for the chosen NXP target, and that code is deployed straight onto the hardware. The main advantage of this approach is what it allows before any board is involved: an application can be validated and tuned in simulation first, and hardware that isn’t physically present can simply be simulated in its place. The results: early issue detection, shorter development cycles, and a faster time to market — backed by a toolchain that has been validated end to end.

_MBDT_One_Slider_2026.jpg

Figure 1. NXP Model-Based Design Toolbox One Pager

4

From the steering wheel to every node


At the heart of the demo is a driver-in-the-loop setup: a physical steering wheel and a set of foot pedals feed signals directly into the simulation, where a virtual car is driven in simulation, into an environment developed through a RoadRunner simulated environment. From there, a clear hierarchy carries every input down to the hardware. The main node — an S32N processor — sits at the center: it communicates with the host PC running the simulation and makes the vehicle-level decisions. It then hands those decisions to a zonal node that acts as a gateway, fanning the signals out to the end nodes that handle each function — the front and rear lights, the front and rear parking sensors, the radar, and the steering rack, and, on the traction side, the battery management system and motor control. The effect is immediate and physical: steering and acceleration in the virtual world set the model on the table moving; shifting into reverse spins the motors up in the right direction; and when an obstacle appears behind the physical car, it stops on its own, with the rear lights turning red across every node — just like a production vehicle. Throughout, a live dashboard built with NXP’s FreeMASTER Lite shows the vehicle state as it happens, from the reverse camera to the parking sensors, blending signals from the virtual world with readings from the physical hardware.

[02.16]NXP AutoWorks Tools Suite 26.jpg

Figure 2. Demo architecture — main node (S32N), zonal gateway, and end nodes.

5

And it grew up along the way


Behind all of these are the core functions of a real car — lighting, parking sensors, steering rack, motor control, and battery management — spread across roughly ten microcontrollers and processors and sixteen NXP evaluation boards and reference designs. There’s no need to unpack every component here, because each one earns its own dedicated article series later on. What’s worth knowing is how it all grew: this didn’t start as today’s car. It began as a battery management system (BMS), then gained cloud connectivity, then motor control — which evolved into a full traction inverter demo — and from there the remaining vehicle domains, from body and lighting to chassis and parking, were layered on one by one until it became a complete vehicle topology. In other words, existing MathWorks and model-based examples were assembled, domain by domain, into a car.

6

Built to be rebuilt — and learned from


Why go to all this trouble? Mostly to document the work, share the thinking behind it, and show how to actually use MBDT. A big part of the appeal is that everything runs on NXP evaluation boards, which means the whole thing can be reproduced. There’s no need to redo a complex custom hardware design before starting; the same boards can be picked up to get going right away. That also makes the demo a hands-on learning platform: a place to explore the model-based workflow by doing one domain at a time.

Note: A word on scope — this is a proof of concept that demonstrates the development workflow, not production firmware as it stands today. A great path forward is NXP’s CoreRide, which you can read more about on this page: Software-Defined Vehicle Development: NXP CoreRide Platform — but that part will not be covered in this series.

Whether the field is automotive, electrification, industrial automation, or robotics — or simply an interest in model-based development — there should be something here worth taking away.

7

A demonstrator, not a blueprint


One last note on how to read all of this. This car is a demonstrator, not a reference design. It was built with the hardware that happened to be on hand, so some of the boards and NXP solutions used aren’t necessarily the optimal fit for a given function — for a specific job, a different microcontroller might serve better. The point was never to say “use exactly these parts.” The point is the steps and the approach: the workflow itself, and how the pieces fit together. With that in mind, the articles below each take a part of this build and show how it’s done.

Welcome to “Hello World” with the Model-Based Design Toolbox.

8

The article series — one domain at a time


Each part of the demo car gets its own dedicated write-up, grouped into the twelve tracks below. As articles go live, the placeholders will be replaced with links. Bookmark this page — it will keep growing.

NXP MBDT — How-To & Introduction

FreeMASTER & FreeMASTER Lite

Parking sensors

  • Overview
  • SW & HW Environment
  • Logic Control (Main model overview)

Lights

  • Overview
  • SW & HW Environment
  • Logic Control (Main model overview)

Motor Control

  • Overview
  • SW & HW Environment
  • Logic Control (Main model overview)

Battery Management Systems

  • Overview
  • SW & HW Environment
  • Logic Control (Main model overview)

Steering

  • Overview
  • SW & HW Environment
  • Logic Control (Main model overview)

Radar

  • Overview
  • SW & HW Environment
  • Logic Control (Main model overview)

Main Node

  • Overview
  • SW & HW Environment
  • Logic Control (Main model overview)

Zone Node

  • Overview
  • SW & HW Environment
  • Logic Control (Main model overview)

Software & Integration

What is next?

Note: This index is updated as new articles are published.
Tags (1)
No ratings
Version history
Last update:
12 hours ago
Updated by: