Table of Contents
Introduction
The Main Node is the central application target used throughout this project. It sits between the simulation environment running on the host PC and the physical hardware that represents the various vehicle domains. While the previous article introduced the purpose of the Main Node and its role within the overall system, this article focuses on the environment that makes that functionality possible.
Developing and validating the Main Node requires more than a target board. The application is modeled, tested, configured, deployed, and monitored using a collection of software tools that work together with the hardware platform. Understanding this environment is important for anyone interested in reproducing the setup or following the remaining articles in the series.
This article describes the software components used during development, the hardware platform used to run the application, and the communication infrastructure that connects the Main Node to the rest of the system.
Figure 1. Position of the Main Node within the system architecture.
Required Software
The Main Node software environment combines MathWorks modeling tools with NXP target support and development utilities. Together, these tools provide the workflow used to model the application, generate code, configure the hardware platform, deploy the software, and observe its behavior during validation and runtime analysis.
3.1 Modeling and Application Development
The Main Node application is developed as a Simulink model.
MATLAB and Simulink are used to describe the behavior of the application before any software is deployed to hardware. Communication interfaces, application states, signal handling, and system-level functionality are assembled and validated within the modeling environment, allowing development to begin long before the target board is involved.
The software environment used for this project includes:
- MATLAB R2024a or newer
- Simulink
- Simulink Coder
- Embedded Coder
- MATLAB Coder
- Stateflow
These tools provide the code-generation workflow that transforms the model into embedded software capable of running on the target hardware.
3.2 Network Definition and Validation
Communication is one of the primary responsibilities of the Main Node. It exchanges information with the simulation environment, the zonal gateways, and the remaining vehicle-domain nodes through a shared CAN network.
Vehicle Network Toolbox is used to bring those communication interfaces directly into MATLAB and Simulink. By using the same DBC definitions during development and validation, communication behavior can be verified before deployment and remain consistent across the complete system.
The shared DBC maintained with CANdb++ acts as a common communication contract between all participating nodes.
Required tools:
- Vehicle Network Toolbox
- CANdb++ 3.1 or newer
3.3 Target Support and Code Generation
The bridge between the Simulink model and the target hardware platform is provided by the required NXP Model-Based Design Toolbox package.
The toolbox provides:
- Main target platform support
- Peripheral integration blocks
- Build integration
- Deployment support
- FreeMASTER integration
Using these components, the generated software can be executed directly on the target hardware without requiring manual integration of low-level peripheral code.
3.4 Build and Configuration Environment
After code generation, the application is built and deployed using the NXP software toolchain integrated inside Model-Based Design Toolbox package. These tools are used to compile, link, and deploy the generated software to the target board.
In parallel, EB tresos is used to maintain the low-level configuration required by the Main Node environment. CAN communication, UART telemetry, I2C initialization, interrupt configuration, and board-level peripheral settings are all managed through this configuration flow.
Together, these tools ensure that the generated software and the target configuration remain aligned throughout development.
3.5 Runtime Monitoring and Validation
Once deployed, the Main Node can be observed through two complementary mechanisms.
FreeMASTER Lite provides runtime visibility into application variables and internal states, while CAN analysis tools are used to inspect the communication exchanged across the network.
These tools are used throughout development and validation activities to verify both application behavior and network communication.
Figure 2. Development workflow used by the Main Node application.
Required Hardware
Unlike the peripheral nodes, the Main Node is responsible for connecting the simulation environment with the physical hardware network. As a result, the hardware environment includes both the target board and the supporting infrastructure used during development, validation, and system-level execution.
4.1 S32N55 Board
The Main Node application executes on an S32N55 board selected for the central application role.
Within this setup, the board serves as the central application platform and hosts the software responsible for coordinating communication between the simulation environment and the zonal gateways.
The board provides:
- CAN FD communication interfaces
- UART communication interfaces
- Debug and deployment connectivity
- I2C peripherals
- Processing resources required by the Main Node application
The Main Node target board is the primary hardware platform referenced throughout this article series.
4.2 Host PC
The host PC provides the environment used to interact with the full setup.
Depending on the activity being performed, it may host:
- MATLAB and Simulink
- RoadRunner simulation environments
- FreeMASTER Lite
- CAN analysis software
The host PC communicates with the Main Node both through the CAN network and through the dedicated telemetry interface used by FreeMASTER.
4.3 CAN Analyzer
A CAN analyzer is used during development and validation to monitor network traffic exchanged between the Main Node and the zonal gateways.
Beyond debugging, the analyzer also provides a convenient method of validating DBC definitions, message timing, and network integration behavior before the full setup is assembled.
Communication and Board-Specific Setup
Several aspects of the Main Node environment are specific to the selected target board and are worth understanding before reproducing the setup.
5.1 Communication Topology
The Main Node does not communicate directly with every vehicle-domain node.
Instead, it exchanges information with the two zonal gateways, which distribute the relevant signals toward the corresponding vehicle-domain nodes.
This arrangement keeps the system organized around a zonal architecture while allowing each subsystem to be developed and validated independently.
5.2 CAN Transceiver Initialization
One hardware-specific detail of the target board concerns the external CAN transceiver.
As a result, the startup sequence requires an I2C initialization step before the FlexCAN controller can begin communication.
Figure 3. CAN transceiver enable sequence on the target board.
5.3 FreeMASTER Telemetry Interface
In addition to the CAN network, the Main Node exposes runtime telemetry through a dedicated UART connection used by FreeMASTER Lite.
This interface is used throughout validation and runtime analysis to visualize application variables and monitor system behavior in real time.
References
Conclusion
This article introduced the environment used to develop, deploy, and validate the Main Node application. It described the software workflow, the hardware platform, and the communication infrastructure that connect the Main Node to both the simulation environment and the physical hardware network.
Particular attention was given to the Main Node's position within the system topology, the UART-based telemetry interface used by FreeMASTER, and the I2C-controlled CAN transceiver initialization required by the target board.
The next article moves beyond the enablement layer and focuses on the Main Node application itself, describing the information it receives, the processing it performs, and the outputs it publishes back into the system network.
