Table of Contents
Introduction
This article belongs to the Front and Rear Lights series and describes the software and hardware environment used throughout the project. Before looking into signal routing, control logic, or integration aspects, it is important to first understand the tools and platforms that support the development and execution of the front and rear lights application.
This article introduces the software components used to develop, configure, and deploy the application, together with the hardware platforms used to demonstrate the lighting functionality. This information provides the foundation needed for the remaining articles in the series.
Model-Based Design sits at the center of the workflow. MathWorks tools handle the modeling of the front and rear lighting control logic, the definition of the CAN communication interfaces, and validation across simulation stages. NXP tools then deploy those models to the S32K3 target platform, wiring the generated application to real-time peripherals, LED driver hardware, and lighting feedback signals.
Required Software
3.1. Vehicle Network Toolbox
Within this workflow, Vehicle Network Toolbox plays a central role in defining, simulating, and validating the CAN interfaces of the front and rear lights module. It brings DBC-driven message definitions directly into Simulink, allowing communication behavior to be tested alongside the control logic long before integration. Every command received from the central controller and every status message sent back to the network is modeled using the exact structure defined in the DBC files, keeping the application perfectly aligned with the vehicle-level specification.
Vehicle Network Toolbox is available as an add-on in MATLAB/Simulink, adding support for CAN communication and DBC-based message definitions.
Figure 1 - Vehicle Network Toolbox
3.2. Stateflow
Stateflow is used to model the control logic of both lighting modules, translating the CAN commands received from the central controller into concrete lighting actions. Each function is represented as a state machine, where transitions are triggered by incoming signals and internal conditions. This approach keeps the logic structured and readable: activation, deactivation, mode switching, and fault handling are all captured in the same diagram.
Stateflow is available as an add-on that can be installed directly from within MATLAB/Simulink, extending the environment with state machine modeling capabilities.
Figure 2 - Stateflow
3.3. NXP Model-Based Design Toolbox for S32K3
NXP Model-Based Design Toolbox for S32K3 is the link between the Simulink model and the S32K3 microcontroller. It takes care of generating the code, building it, and running it on the target, turning the lighting model into a real embedded application. Through its peripheral blocks, the model can directly use the resources needed by the front and rear lights modules, such as DIO, CAN, and UART without leaving the Simulink environment. It also connects to the NXP configuration tools and supports FreeMASTER for real-time monitoring, which makes it easy to check how the lighting logic actually behaves on the hardware.
Figure 3 - Development flow diagram
Required Hardware
4.1. FRDM Automotive S32K312 Development Board (FRDM-A-S32K312)
The front and rear lights application runs on the FRDM Automotive S32K312 Development Board, a development platform based on the NXP S32K312 microcontroller. The board provides access to the communication interfaces and processing capabilities of the target device while offering an integrated platform for software development, debugging, and validation activities.
Within the scope of this project, the board is used to execute the lighting application and exchange messages with the central controller through the CAN network. Its communication interfaces, debugging connectivity, and expansion capabilities make it suitable for evaluating body electronics use cases and lighting control scenarios.
Figure 4 - FRDM Automotive S32K312 Development Board
4.2. CAN analyzer
Emulates the central controller when the node is not yet integrated with the full system. It injects the CAN commands defined in the DBC files (turn signals, headlight modes, hazard, brake indication, etc.) and captures the status messages sent back by the module, enabling the CAN interface and control logic to be validated in a controlled and repeatable way.
4.3. Addressable LED Strip
The physical lighting output is represented by an addressable LED strip, in which each LED can be controlled individually. This makes it possible to reproduce all the relevant lighting functions on a single strip - turn signals, hazard lights, headlight modes, and brake indication - by assigning different LEDs or groups of LEDs to each function. The result is a clear visual representation of the module's behavior, making it easy to demonstrate how the control logic reacts to incoming CAN commands.
References
Conclusion
This article described the software and hardware enablement required for the front and rear lights modules. The software environment combines MathWorks modeling and vehicle network capabilities with NXP target support, while the hardware environment brings together the FRDM Automotive S32K312 Development Board, a CAN analyzer, and an addressable LED strip. Together, these elements provide the foundation for modeling, simulation, communication, code generation, deployment, and validation of the lighting application.
The next article will focus on the architecture and model description of the front and rear lights modules, including the control logic, CAN interfaces, and overall application structure.