System Design Workflow Tutorial

This comprehensive tutorial guides you through the complete process of designing, configuring, and deploying a multi-ECU automotive system in TrueFidelity Desktop. You'll learn how to create a realistic ECU network topology, configure hardware settings, build firmware, and monitor running systems in real-time.

Overview

Goal: Build a complete automotive drive cycle simulation system with multiple ECUs connected via CAN bus, configure their properties, deploy them as Docker containers, and monitor their real-time execution using TrueFidelity's comprehensive monitoring tools.

What You'll Learn:

• Creating and organizing system projects in TrueFidelity
• Building ECU network topologies using the visual System Canvas
• Configuring ECU hardware and software properties
• Understanding the relationship between ECUs and Network buses
• Deploying ECU containers and managing their lifecycle
• Monitoring system performance and debugging issues
• Exporting configurations for team collaboration

Time estimate: 20-30 minutes for complete walkthrough

Prerequisites:

• TrueFidelity Desktop installed and license activated
• Docker Desktop running and accessible
• Basic understanding of automotive ECU concepts
• ECU firmware binaries for deployment

Step 1: Create a New System

Let's begin by creating a new TrueFidelity system project. This will be the container for all your ECUs, networks, and configurations.

1. Launch TrueFidelity Desktop
2. Wait for the application to fully load

3. You should see the welcome screen or an empty workspace

4. Create a new system project using the File menu

5. Navigate to File → New in the menu bar
6. Alternatively, use the keyboard shortcut Ctrl+N (Windows/Linux) or Cmd+N (macOS)

1. Configure your new system in the New System dialog:
2. System name: Enter Drive Cycle - this will be your project identifier
3. Description (optional): Add "Electric vehicle drive cycle simulation with pedal inputs and motor control"
4. Save location: Click Browse and select your projects folder (e.g., ~/Documents/TrueFidelity/Projects)
5. Leave other settings at their defaults for now

1. Click Create to generate your system

After creation, TrueFidelity automatically opens the System Design workspace. You'll see three main areas:

• Left panel: Toolbox containing draggable components
• Center: System Canvas (currently empty) where you'll build your topology
• Right panel: Properties panel for configuring selected elements

Understanding the Workspace

The System Design mode is specifically optimized for creating ECU topologies. The layout is inspired by professional CAD tools, with a component library on the left, workspace in the center, and properties on the right. This arrangement allows for efficient drag-and-drop system design.

Panel Management

If any panels are missing, you can restore them via View → Panels menu. The Toolbox is essential for this tutorial - ensure it's visible before proceeding.

Step 2: Add ECUs to the Canvas

Now we'll add Electronic Control Units (ECUs) to build our automotive system. ECUs are the computational nodes that will run your firmware and communicate over the network.

Understanding the Toolbox

1. Locate the Toolbox panel on the left side of the screen
2. It contains two main categories: Components and Networks
3. Each category can be expanded to show available items

1. Expand the Components category by clicking the arrow next to "Components (1)"
2. You'll see "ECU - Electronic Control Unit" listed
3. This is a generic ECU template that can be configured for different purposes

Adding Your First ECU

1. Add a VCU (Vehicle Control Unit) to the canvas:
2. Click and hold on the "ECU" item in the Toolbox
3. Drag it onto the empty canvas area
4. Release the mouse button to place the ECU
5. The ECU appears as a UML-style component box with the label "«ECU»"

1. Position the VCU in the upper-left area of the canvas
2. Click on the ECU to select it (you'll see blue selection handles)
3. The ECU label will initially show a generic name
4. We'll configure its specific properties in the next step

Adding Additional ECUs

1. Add two more ECUs for a complete system:
2. Drag another ECU from the Toolbox and place it in the upper-right area
3. This will be your MCU (Motor Control Unit)
4. Drag a third ECU and place it in the lower area
5. This will be your BMS (Battery Management System)

Your canvas should now display three ECU nodes:

Canvas Navigation

• Zoom: Use your mouse wheel or the zoom controls in the toolbar
• Pan: Hold right-click and drag, or use middle mouse button
• Select: Left-click on any element
• Multi-select: Hold Ctrl/Cmd and click multiple elements
• Grid snap: Elements automatically align to the grid for neat layouts

ECU Visualization

ECUs are displayed using UML component notation (rectangular boxes with small squares on the side). This is a standard representation familiar to automotive engineers. The gray color indicates they're not yet configured or running.

Step 3: Configure ECU Properties

Each ECU needs to be configured with hardware specifications, software settings, and firmware options. Let's start with the VCU.

Configuring the VCU (Vehicle Control Unit)

1. Select the VCU by clicking on it
2. The ECU will show blue selection handles around its border
3. The Properties panel on the right automatically updates to show ECU settings

1. Review the Properties Panel structure on the right side:
2. GENERAL section: Basic identification (Name, ID)
3. HARDWARE section: Board selection, memory, and flash settings
4. SOFTWARE section: Operating system and firmware configuration

5. DEBUG section: Development and debugging options

6. Configure the VCU properties:

GENERAL Settings:

• Name: Change from default to VCU
• ID: Automatically generated (e.g., ecu-1763540145789) - leave as is

HARDWARE Settings:

• Board: Select S32K3X4EVB from the dropdown
• Memory: Enter 16MB (appropriate for Zephyr-based MCUs)
• Flash: Enter 2MB for flash storage

SOFTWARE Settings:

• Operating System: Select Zephyr from the dropdown
• Firmware Mode: Choose between:
  • Binary File: Use a pre-compiled firmware binary (.elf, .bin, .hex)
  • Source Code: Build from source using TrueFidelity's build system
• For this tutorial, select Binary File mode
• Firmware Binary: Click "Browse" to select a firmware file

1. Click "Apply Changes" button at the bottom of the Properties panel
2. This saves your configuration to the ECU node
3. The ECU label updates to show "VCU" and the board type

Configuring the MCU (Motor Control Unit)

1. Select the MCU (upper-right node) and configure:
2. Name: MCU
3. Board: S32K3X4EVB (same board family as VCU)
4. Memory: 16MB
5. Flash: 2MB
6. Operating System: Zephyr
7. Firmware Mode: Binary File
8. Click Apply Changes

Configuring the BMS (Battery Management System)

1. Select the BMS (lower node) and configure:
2. Name: BMS
3. Board: S32K3X4EVB (same board family)
4. Memory: 16MB
5. Flash: 2MB
6. Operating System: Zephyr
7. Firmware Mode: Binary File
8. Click Apply Changes

After configuration, your ECUs will display their names and board types on the canvas.

Hardware Board Selection

TrueFidelity supports various automotive development boards including: - S32G274A: High-performance processors for gateway applications - S32K3X4: General-purpose automotive MCUs for body and powertrain - IMX8: Application processors for infotainment - Custom boards can be added through configuration files

Firmware Options

• Binary File Mode: Quick deployment using pre-built binaries
• Source Code Mode: Full build integration with TrueFidelity's build system
• The "Build Firmware" button (green) becomes active when source code mode is selected

Step 4: Add Network Bus and Create Connections

In TrueFidelity, networks are represented as separate bus nodes that ECUs connect to, accurately modeling real automotive architectures where multiple ECUs share a common communication bus.

Understanding Network Architecture

Before we proceed, it's important to understand how automotive networks work:

• ECUs don't connect directly to each other
• Instead, they connect to shared network buses (CAN, LIN, Ethernet, FlexRay)
• Multiple ECUs can connect to the same bus
• Messages broadcast on the bus are visible to all connected ECUs

Adding a CAN Bus

1. Expand the Networks category in the Toolbox
2. Click the arrow next to "Networks (1)"
3. You'll see "CAN Bus - Controller Area Network" listed

1. Drag a CAN Bus onto the canvas:
2. Click and hold on "CAN Bus" in the Toolbox
3. Drag it to the center area between your three ECUs
4. Release to place the network bus
5. The CAN bus appears as a red horizontal bar (red is the standard color for CAN)

1. Position the CAN Bus centrally:
2. Place it roughly in the middle of your three ECUs
3. The bus can be resized by dragging its edges if needed

Connecting ECUs to the Network

1. Connect the VCU to the CAN Bus:
2. Hover over the VCU - you'll see small blue connection handles appear
3. Click and drag from one of the handles
4. Drag the connection line to the CAN bus
5. Release when the bus highlights, indicating a valid connection
6. A blue connection line appears between the ECU and the bus

1. Connect the remaining ECUs:
2. Connect the MCU to the same CAN bus using the same drag technique
3. Connect the BMS to the CAN bus
4. All three ECUs are now on the same network

Your system should now show all three ECUs connected to a central CAN bus:

Understanding Network Visualization

Notice the visual elements:

• CAN Bus: Displayed as a red horizontal bar with "CAN Bus 1" label
• Baud rate: Shows "500k" indicating 500,000 bits per second
• Connection lines: Blue lines from ECUs to the bus
• Connection handles: Small circles that appear on hover for creating connections

Step 5: Configure Network Properties

Now let's configure the CAN bus parameters to match your system requirements.

1. Select the CAN Bus by clicking on the red network bar
2. The bus will show selection highlights
3. The Properties panel updates to show network configuration

1. Configure network settings in the Properties Panel:

GENERAL Settings:

• Name: Keep as "CAN Bus 1" or rename to "Main CAN"
• ID: Auto-generated network identifier

CONFIGURATION Settings:

• Network Type: CAN (already set)
• Baud Rate: 500000 (500 kbps - standard for powertrain)
• Channel: can0 (the Linux network interface name)

• DBC File: (Optional) Browse to select a DBC database file for signal definitions

• Apply the configuration:

• Click Apply Changes to save the network settings
• The bus label updates to show the baud rate

Common CAN Baud Rates

• 125 kbps: Low-speed body electronics
• 250 kbps: General body control
• 500 kbps: Powertrain and chassis (most common)
• 1 Mbps: High-speed diagnostic

Network Colors

TrueFidelity uses color coding for quick network identification: - Red: CAN bus - Light Blue: LIN bus - Dark Blue: Ethernet - Green: FlexRay

Step 6: Save the System

It's important to save your work regularly. TrueFidelity stores your complete system configuration including all ECUs, networks, and connections.

1. Save your system using one of these methods:
2. Press Ctrl+S (Windows/Linux) or Cmd+S (macOS)
3. Click File → Save from the menu bar
4. Click the Save icon in the toolbar

1. Verify the save location:
2. The save dialog shows your project folder
3. File name: truefidelity-system.json (default name)

4. This is a JSON file containing your complete system definition

5. Confirm the save was successful:

6. Look for "System saved" notification in the bottom-right
7. The window title updates to show the saved file name
8. The save icon in the toolbar becomes grayed out

Auto-save Feature

TrueFidelity automatically saves your work every 5 minutes by default. You can adjust this in Settings → Preferences → Auto-save interval.

File Format

The truefidelity-system.json file contains: - ECU configurations and properties - Network topology and connections - Firmware paths and build settings - Diagram layouts and visual positions - Project metadata and version information

Step 7: Build Firmware (Optional)

If you have firmware source code and want to build it within TrueFidelity, this section guides you through the integrated build process. Skip this if you're using pre-built binaries.

Understanding the Build System

TrueFidelity includes an integrated firmware build system that:

• Uses Docker containers with pre-configured toolchains (Zephyr SDK, ARM GCC, etc.)
• Supports Zephyr RTOS projects with west build integration
• Provides real-time progress feedback during compilation
• Automatically detects board configurations from your source code

Switching to Source Code Mode

1. Select an ECU that you want to build firmware for (e.g., VCU)

2. Change to Source Code mode in the Properties panel:

3. Scroll to the SOFTWARE section
4. Find the Firmware Mode option
5. Select Source Code radio button
6. New configuration fields appear below

1. Configure the source code paths:

Source Root: - Click Browse next to the Source Root field - Navigate to your firmware application directory (e.g., s32k3-vcu-demo/app) - This should be the directory containing your Zephyr application - The path appears in the field after selection

CMakeLists.txt Path: - Click Browse next to the CMakeLists Path field - Select the CMakeLists.txt file in your application directory - This file defines your Zephyr build configuration

1. Verify source configuration:
2. Both paths should point to valid locations
3. The Source Root should contain a boards/ directory with your board definition
4. The CMakeLists.txt should reference the correct board (e.g., s32k3x4evb)

Starting the Build

1. Initiate the build process:
2. Click the green Build Firmware button in the Properties panel
3. A build dialog appears showing your configuration

1. Start the build:
2. Review the build configuration in the dialog
3. Click the Start button to begin compilation

4. The dialog transitions to show build progress

5. Monitor build progress:

6. The dialog shows real-time progress percentage (0% → 100%)
7. Build stages include:
   • Loading Zephyr modules
   • Configuring CMake
   • Compiling source files
   • Linking executable
8. Typical build time: 1-3 minutes for a simple application

1. Observe the build output:
2. Component messages appear as drivers are included: Load components for S32K344: driver_common component is included. driver_flexcan component is included. driver_lpspi component is included. driver_lpuart component is included.
3. Compilation progress shows files being built: [120/170] Building C object zephyr/drivers/spi/... [150/170] Linking C static library... [169/170] Linking C executable zephyr/zephyr.elf

Build Output

1. Review build results:

On Success: - A success message displays confirming the build completed - The firmware binary path automatically updates in ECU properties - The binary is ready for deployment (typically zephyr.elf) - Click Close to dismiss the dialog

On Failure: - Error messages display in the build output - Common issues include: - Missing board definition files - Incorrect CMakeLists.txt configuration - Missing device tree nodes - Check the error message for specific file and line information

1. Click Apply Changes to save the firmware configuration

Firmware Source Requirements

For successful builds, your firmware source should include:

app/
├── CMakeLists.txt          # Zephyr build configuration
├── prj.conf                # Kconfig settings
├── src/
│   └── main.c              # Application source code
└── boards/
    └── arm/
        └── s32k3x4evb/     # Custom board definition
            ├── s32k3x4evb.dts
            ├── s32k3x4evb_defconfig
            ├── s32k3x4evb-pinctrl.dtsi
            └── Kconfig.board

TrueFidelity Build System

The integrated build system uses:

• Docker containers: Pre-configured Zephyr SDK and toolchains
• West build: Standard Zephyr build tool integration
• Board auto-detection: Reads board name from CMakeLists.txt
• Incremental builds: Faster rebuilds after initial compilation

Build Best Practices

• Ensure your board definition matches the ECU's Board setting in Properties
• Keep the Source Root path as short as possible to avoid path length issues
• If builds fail, check that all required device tree nodes are defined
• Use the Memory region output to verify your application fits in available flash/RAM

Common Build Errors

• "No board named 'xyz' found": Add board definition to boards/arm/<board>/ directory
• "BOARD_ROOT element without 'boards' subdirectory": Set BOARD_ROOT in CMakeLists.txt to the directory containing boards/
• Device tree errors: Ensure all referenced nodes (like &lpspi1) are enabled in the DTS file

Step 8: Deploy and Start ECUs

Now we'll deploy your ECUs as Docker containers and start them running. This is where your static design becomes a live, executing system.

Starting the System

1. Start the entire system from the toolbar:
2. Locate the Start button in the main toolbar (green play icon)
3. Click it to begin system deployment
4. A progress dialog appears showing "Starting ECUs..."

Toolbar Start vs Individual Start

The toolbar Start button deploys all ECUs simultaneously. There's no right-click context menu on individual ECUs - use the toolbar for system-wide control.

1. Monitor the startup process:
2. ECUs transition through states: Stopped → Starting → Running
3. The STATUS column shows a green dot when running
4. CPU and Memory values begin updating with real-time data

5. UPTIME starts counting from 00:00:00

6. Wait for all ECUs to reach Running state:

7. All three ECUs (VCU, MCU, BMS) start in parallel
8. Full system startup usually takes 10-30 seconds

Understanding the ECU Status Panel

The ECU Status panel shows the state of all ECUs in your system:

• ECU: Name of each ECU
• STATUS: Current state (Stopped/Running)
• IMAGE: Docker image being used
• CPU: Processor usage percentage
• MEMORY: RAM usage
• NETWORK I/O: Data transfer rates
• UPTIME: How long the ECU has been running

If the ECU Status panel is not visible, open it via View → Panels → ECU Status.

Understanding Status Indicators

The ECU Status panel uses visual indicators:

• Green dot + "Running": ECU is active and healthy
• Gray dot + "Stopped": ECU is not deployed
• Yellow dot + "Starting": ECU is being deployed
• Red dot + "Error": ECU failed to start (check Console for details)

Resource Monitoring

Once running, observe the resource usage:

• CPU %: Shows processor load (normal: 0.1-5% idle, 20-80% under load)
• Memory: Displays RAM usage in MB (should match configured limits)
• Network I/O: Updates when ECUs communicate over CAN bus

Performance Indicators

• Low CPU usage (< 1%) indicates idle ECUs
• Sudden CPU spikes might indicate processing events
• Memory should remain stable unless there's a leak
• Network I/O increases during message broadcasts

Docker Requirement

If ECUs fail to start, ensure: - Docker Desktop is running - Docker service has sufficient resources allocated - No firewall blocking Docker operations

Step 9: Monitor Running System

With your ECUs running, TrueFidelity provides comprehensive monitoring tools to observe system behavior, debug issues, and validate functionality. Let's explore each monitoring capability.

View ECU Hardware Status

The ECU Status panel provides your primary health dashboard:

1. Verify system health:
2. All three ECUs should show green "Running" status
3. CPU usage typically stays below 5% when idle

4. Memory usage should be stable and within configured limits

5. Identify resource patterns:

6. VCU may show slightly higher CPU when processing pedal sensor inputs
7. MCU and BMS should have similar resource profiles
8. Network I/O spikes indicate active CAN communication

View Console Logs

The ECU Console aggregates logs from all running ECUs in real-time:

1. Open the ECU Console panel:
2. Click the Console tab in the bottom panel area
3. Logs begin streaming immediately from all ECUs
4. Each line shows: Timestamp, Level, Source ECU, and Message

1. Understanding log structure: 15:25:24.991 INF Vcu [00:04:13.213,000] e[0m<inf> s32k3_pedal_demo: ACCEL : status=0x01...
2. 15:25:24.991: Wall clock time
3. INF: Log level (INFO)
4. Vcu: Source ECU name
5. [00:04:13.213,000]: ECU runtime timestamp

6. Message content: Actual log data

7. Filter logs effectively:

8. Filter by ECU: Select specific ECU from dropdown (e.g., "Vcu")
9. Filter by level: Toggle INFO, WARNING, ERROR, DEBUG buttons
10. Text search: Type keywords in the filter box

11. Auto-scroll: Keeps latest logs visible (toggle off to inspect specific entries)

12. Console controls:

13. Pause: Freezes log display for detailed inspection
14. Clear: Removes all logs from display (doesn't affect ECU operation)
15. Export: Saves current logs to file for analysis

Debugging with Logs

• Watch for ERROR level messages (red) indicating problems
• INFO messages (white) show normal operation flow
• DEBUG messages (gray) provide detailed internal state
• Correlation IDs in messages help trace request flows

Monitor Resources

1. Open the Resource Monitor panel:
2. Shows real-time CPU and memory graphs
3. Each ECU has its own colored line
4. X-axis shows time, Y-axis shows percentage/MB

1. Interpret the graphs:
2. Steady lines: System running normally
3. Spikes: Processing events or message handling
4. Gradual increase: Possible memory leak

5. Sudden drops: ECU restart or resource release

6. Adjust monitoring window:

7. Use dropdown to select: 1 min, 5 min, 15 min, 30 min
8. Shorter windows show more detail
9. Longer windows reveal trends

View Network Traffic

The Network Traffic panel displays CAN bus communication:

1. Monitor CAN messages:
2. Real-time display of all CAN frames
3. Shows ID, DLC, Data, Timestamp, and Count
4. Updates as ECUs exchange messages

1. Filter traffic:
2. By CAN ID (e.g., 0x123)
3. By source ECU

4. By data patterns

5. Analyze communication patterns:

6. Periodic messages (heartbeats, status)
7. Event-driven messages (state changes)
8. Request-response pairs

Access ECU Terminals

The Terminal panel provides shell access to ECU containers:

1. Open the Terminal panel:
2. Located in the bottom panel area

3. Shows a dropdown selector for ECU choice

4. Select an ECU for terminal access:

5. Use the dropdown to choose an ECU (e.g., "VCU")
6. Terminal connects automatically if the OS supports it
7. Shell prompt appears when connected

1. Execute diagnostic commands: ```bash # Check running processes ps aux

# View memory usage cat /proc/meminfo

# Check network interfaces ip addr show

# View CAN interface status ip link show can0 ```

Terminal Availability

Terminal access requires: - ECU running Linux-based OS (FSL Linux, Ubuntu, etc.) - Debug mode enabled in ECU configuration - Proper shell binary in the container image - Note: The VCU, MCU, and BMS in this tutorial use Zephyr OS, which has limited terminal support. For full terminal access, use Linux-based ECUs.

Monitoring Best Practices

• Keep Console open during testing to catch errors immediately
• Use Resource Monitor to identify performance bottlenecks
• Export logs before stopping ECUs to preserve diagnostic data
• Terminal access is powerful but should be used carefully in production

Stopping the System

When you're done monitoring or need to make changes:

1. Stop all ECUs using the toolbar:
2. Click the Stop button (red square icon) in the main toolbar
3. All ECUs begin shutting down simultaneously
4. STATUS changes from "Running" to "Stopping" to "Stopped"

1. Verify clean shutdown:
2. Check Console for any error messages during shutdown
3. ECU Status panel shows all ECUs with gray "Stopped" status

Step 10: Debugging ECUs (Optional)

TrueFidelity supports remote debugging of ECU firmware using GDB. This allows you to set breakpoints, inspect variables, and step through code while the ECU runs in the simulated environment.

Enable Debug Mode

Before starting the system, you must enable debugging for the ECU you want to debug:

1. Select the ECU on the System Canvas (e.g., VCU)

2. Enable debug options in the Properties panel:

3. Scroll to the DEBUG section
4. Check Enable Debug Mode to activate the GDB server
5. Optionally check Wait for Debugger if you want the ECU to pause at startup until a debugger connects

1. Click Apply Changes to save the debug settings

Enable Before Starting

Debug mode must be enabled before starting the system. If the system is already running, stop it first, enable debug mode, then restart.

Get Debug Configuration

Once debug mode is enabled, TrueFidelity provides ready-to-use debug configurations:

1. Select the ECU with debug mode enabled

2. Locate the debug configuration options in the Properties panel DEBUG section:

3. GDB Client Command: The command line to connect a GDB client
4. VS Code Launch Config: A JSON configuration for VS Code debugging

1. Copy the configuration you need:
2. Click the Copy button next to the GDB command or VS Code config
3. The configuration is copied to your clipboard

Using VS Code for Debugging

To debug your ECU firmware in VS Code:

1. Start the system with debug mode enabled
2. The ECU will start with GDB server listening

3. If "Wait for Debugger" is enabled, the ECU pauses until you connect

4. Open your firmware project in VS Code

5. Create or update launch.json:

6. Open the Run and Debug panel (Ctrl+Shift+D)
7. Click "create a launch.json file" or open existing .vscode/launch.json
8. Paste the copied VS Code Launch Config

Example configuration: json { "version": "0.2.0", "configurations": [ { "name": "Debug VCU", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/firmware.elf", "MIMode": "gdb", "miDebuggerPath": "/usr/bin/gdb-multiarch", "miDebuggerServerAddress": "localhost:3333", "setupCommands": [ { "description": "Enable pretty-printing", "text": "-enable-pretty-printing", "ignoreFailures": true } ] } ] }

1. Set breakpoints in your source code:
2. Open your firmware source file

3. Click in the gutter (left margin) to set a breakpoint (red dot appears)

4. Start debugging:

5. Select the debug configuration from the dropdown
6. Press F5 or click the green play button
7. VS Code connects to the GDB server running in TrueFidelity

1. Debug your firmware:
2. Execution pauses at your breakpoint
3. Use the debug toolbar to step through code (Step Over, Step Into, Continue)
4. Inspect variables in the Variables panel
5. View the call stack in the Call Stack panel

Using GDB Command Line

For command-line debugging:

1. Start the system with debug mode enabled

2. Open a terminal and run the GDB client command: bash gdb-multiarch -ex "target remote localhost:3333" build/firmware.elf

3. Use standard GDB commands: (gdb) break main # Set breakpoint at main (gdb) continue # Continue execution (gdb) next # Step over (gdb) step # Step into (gdb) print variable # Print variable value (gdb) backtrace # Show call stack

Debug Multiple ECUs

Each ECU with debug enabled gets its own GDB port. Check the Properties panel for the specific port assigned to each ECU.

Performance Impact

Debug mode adds overhead to ECU execution. Disable it for performance testing or when debugging is not needed.

Step 11: Cleanup and Best Practices

After completing your tutorial session, properly clean up resources and prepare for future work.

Clean Up Resources

1. Export valuable data before closing:
2. Export logs: Click Export in Console panel to save diagnostic data

3. Document findings: Note any issues or observations for future reference

4. Close the system project:

5. Click File → Close
6. Choose to save any unsaved changes

7. The workspace returns to empty state

8. Clean up Docker resources (optional): ```bash # List TrueFidelity containers docker ps -a | grep truefidelity

# Remove stopped containers docker container prune

# Clean up unused networks docker network prune ```

1. Archive or delete tutorial files:
2. Navigate to your project folder
3. Archive truefidelity-system.json for reference
4. Or delete if this was just for learning

What You've Learned

Congratulations! You've successfully:

• ✅ Created a multi-ECU automotive system from scratch
• ✅ Configured ECU hardware and software properties
• ✅ Built network topology with CAN bus connections
• ✅ Deployed ECUs as Docker containers
• ✅ Monitored real-time system behavior
• ✅ Debugged using logs and console access

Next Steps

Immediate Next Steps

1. Explore advanced monitoring:
2. Read the ECU Monitoring Walkthrough tutorial for deep-dive debugging
3. Learn about Signal Analysis for CAN message inspection

4. Master Performance Profiling techniques

5. Build real firmware:

6. Follow the Build Configuration Guide to compile actual ECU code
7. Set up the tf-build toolchain for cross-compilation

8. Integrate your existing firmware projects

9. Customize your workspace:

10. Explore Workspaces & Layouts to create role-specific views
11. Save custom layouts for different workflows
12. Configure keyboard shortcuts for efficiency

Advanced Topics

• Multi-Network Systems: Create complex topologies with multiple CAN/LIN buses
• Gateway Routing: Configure message routing between networks
• HIL Integration: Connect to real hardware for Hardware-in-Loop testing
• Scripting and Automation: Use TrueFidelity's API for automated testing
• Cloud Deployment: Deploy systems to Kubernetes clusters

Learning Resources

• Documentation: Review Reference section for detailed feature guides
• Video Tutorials: Watch walkthroughs on the TrueFidelity YouTube channel
• Community Forum: Join discussions and get help from other users
• Support: Contact support@truefidelity.io for technical assistance

Troubleshooting Guide

Common Issues and Solutions

ECUs Won't Start

Symptoms: ECUs remain in "Stopped" state, won't transition to "Running"

Solutions: 1. Verify Docker Desktop: - Ensure Docker Desktop is running (check system tray) - Restart Docker Desktop if needed - Check Docker resources (Settings → Resources → ensure adequate CPU/memory)

1. Check error messages:
2. Open Console panel before starting ECUs
3. Look for red ERROR messages during startup

4. Common errors: "Image not found", "Port already in use"

5. Validate configuration:

6. Ensure firmware paths are correct (if specified)
7. Verify memory limits are reasonable (minimum 128MB)
8. Check network configuration is valid

Terminal Connection Fails

Symptoms: Terminal panel shows "Connection failed" or remains blank

Solutions: 1. Verify ECU compatibility: - Only Linux-based OS ECUs support terminal (FSL Linux, Ubuntu) - FreeRTOS and Zephyr ECUs don't have shell access

1. Check ECU status:
2. ECU must be in "Running" state

3. Wait 10-15 seconds after start for initialization

4. Enable debug mode:

5. Select ECU in System Canvas
6. In Properties, check "Enable" under DEBUG section
7. Apply changes and restart ECU

Network Traffic Not Appearing

Symptoms: Network Traffic panel empty despite running ECUs

Solutions: 1. Verify network setup: - Ensure ECUs are connected to the same network bus - Check CAN bus configuration matches ECU expectations

1. Check filters:
2. Clear any filters in Network Traffic panel

3. Ensure correct bus is selected if multiple networks exist

4. Validate firmware:

5. Firmware must actively send CAN messages
6. Check Console for "CAN init" or network startup messages

High Resource Usage

Symptoms: Host system slows down, high CPU/memory usage

Solutions: 1. Limit concurrent ECUs: - Start with fewer ECUs initially - Add more gradually while monitoring resources

1. Adjust resource limits:
2. Reduce ECU memory allocations in Properties

3. Set CPU limits in Docker export configuration

4. Optimize Docker settings:

5. Docker Desktop → Settings → Resources
6. Reduce CPUs and memory allocated to Docker
7. Enable resource limits per container

Pro Tip

Keep the Console panel visible during all operations - most issues reveal themselves through error messages before symptoms appear in the UI.

Getting Help

If you encounter issues not covered here: 1. Check the Reference → FAQ section 2. Search the community forum 3. Contact support with: - System logs (exported from Console) - System configuration (.tfsystem file) - Screenshots of the issue - Docker and OS version information