ECU Monitoring Walkthrough

This comprehensive tutorial guides you through monitoring, analyzing, and debugging running ECU systems in TrueFidelity Desktop. You'll master the monitoring panels, learn to identify performance issues, access diagnostic tools, and export data for analysis. Whether you're tracking real-time performance, debugging issues, or conducting long-term analysis, this tutorial provides the essential monitoring skills.

Overview

Goal: Master TrueFidelity's monitoring capabilities to track ECU performance, diagnose issues in real-time, analyze network traffic, access terminal debugging tools, and export comprehensive diagnostic data for reporting and analysis.

What You'll Learn:

• Setting up optimal monitoring layouts for different scenarios
• Understanding ECU status indicators and health metrics
• Filtering and analyzing console logs effectively
• Tracking resource usage and identifying performance issues
• Monitoring CAN network traffic and message patterns
• Using terminal access for advanced debugging
• Exporting and correlating monitoring data
• Troubleshooting common issues using monitoring tools

Time estimate: 20-25 minutes for complete walkthrough

Prerequisites:

• TrueFidelity Desktop installed and license activated
• A running ECU system (or complete the System Design Workflow tutorial first)
• Basic understanding of system monitoring concepts
• Docker Desktop running

Step 1: Set Up Monitoring Layout

TrueFidelity provides predefined layouts optimized for different workflows. Let's set up the ideal monitoring environment for tracking running ECUs.

Understanding Layout Modes

TrueFidelity offers three primary layout modes:

• System Design Mode: Focus on canvas and properties for building topologies
• Monitoring Mode: Optimized for runtime monitoring with status and resource panels
• CAN Log Analysis Mode: Specialized for network traffic and signal analysis

Switch to Monitoring Mode

1. Open the View menu from the menu bar
2. Click View → Layouts → ECU Monitoring
3. The workspace reorganizes automatically for monitoring tasks

After switching, the workspace displays the monitoring layout:

1. Verify essential panels are visible:

2. ECU Hardware Status: Bottom panel showing all ECU states

3. ECU Console: Log streaming panel for runtime messages
4. ECU Resource Monitor: Real-time CPU and memory graphs
5. ECU Task Monitor: Process and thread information

6. Terminal: Shell access panel (dropdown-based)

7. Arrange panels for your workflow:

8. Drag panel tabs to reposition them

9. Resize panels by dragging the divider lines between them
10. Create tab groups by dragging one panel onto another
11. Dock panels to edges by dragging to the blue drop zones

Customize Your Layout

1. Optimize panel sizes based on priority:

2. Make Console larger if focusing on logs

3. Expand Resource Monitor for performance analysis
4. Minimize panels you don't need immediately

Layout Best Practices

• Performance Monitoring: Maximize Resource Monitor and Task Monitor
• Debugging: Focus on Console and Terminal panels
• Network Analysis: Prioritize Network Traffic and Signal Viewer
• Overview: Balance all panels equally for general monitoring

Panel Shortcuts

While some panels have keyboard shortcuts, the most reliable way to access panels is through the View menu. Panel visibility can also be toggled from the toolbar panel buttons when available.

Step 2: Monitor ECU Hardware Status

The ECU Hardware Status panel is your primary dashboard for monitoring the health and state of all ECUs in your system. This panel provides real-time visibility into container states, resource usage, and system health.

Understanding the ECU Hardware Status Panel

1. Locate the ECU Hardware Status panel
2. Usually positioned at the bottom of the screen in Monitoring mode

3. Shows a table with one row per ECU in your system

4. Review the information columns:

5. ECU: Name identifier for each ECU

6. STATUS: Current operational state with color indicator
7. IMAGE: Docker container image in use
8. CPU: Real-time processor usage percentage
9. MEMORY: Current RAM consumption
10. NETWORK I/O: Data transfer rates (bytes/sec)
11. UPTIME: Time since ECU started

Understanding Status Indicators

The STATUS column uses color-coded indicators to show ECU states:

• Green dot + "Running": ECU is operational and healthy
• Gray dot + "Stopped": ECU is not deployed or has been stopped
• Yellow dot + "Starting": ECU is in the process of launching
• Red dot + "Error": ECU failed to start or crashed

Status Color Meanings

Since it's difficult to capture all status colors simultaneously, here's what each indicates: - Green (Running): Normal operation, container executing successfully - Yellow (Starting): Transitional state, usually lasts 5-10 seconds - Red (Error): Requires investigation - check Console for error details - Gray (Stopped): Expected when system is not running

System-Wide Controls

ECUs are managed as a complete system through the main toolbar:

1. Starting the system:
2. Click the Start button (green play icon) in the toolbar
3. All ECUs begin deployment simultaneously
4. Status changes from Stopped → Starting → Running

1. Stopping the system:
2. Click the Stop button (red square) in the toolbar
3. All ECUs shut down gracefully
4. Status changes from Running → Stopping → Stopped

1. System validation:
2. Click the Validate button to check configuration
3. Ensures all ECU settings are correct before starting

No Individual ECU Control

Unlike some systems, TrueFidelity operates ECUs as a coordinated system. There are no right-click menus or individual start/stop controls for ECUs. Use the toolbar buttons for all system control operations.

Interpreting Resource Metrics

Understanding resource usage helps identify performance issues:

CPU Usage Patterns

• 0.1-1%: Idle ECU, normal for waiting state
• 5-20%: Active processing, typical during message handling
• 50-70%: Heavy processing, may be normal for certain operations
• 80-100%: High load, investigate if sustained

Memory Usage Indicators

• Stable value: Normal operation
• Gradual increase: Possible memory leak
• Sudden spike: Large data processing or allocation
• At limit: May cause performance issues or crashes

Network I/O Metrics

• Low/Zero: ECU not actively communicating
• Periodic spikes: Normal message broadcast patterns
• Constant high: Heavy network traffic, verify if expected
• Zero when expected traffic: Possible network configuration issue

Sorting and Filtering

1. Sort by any column to identify outliers:
2. Click column headers to sort ascending/descending
3. Sort by CPU to find heavy processors
4. Sort by Memory to identify memory consumers

5. Sort by Uptime to see which ECUs started first

6. Quick identification techniques:

7. High CPU: Sort by CPU%, investigate top consumers
8. Memory leaks: Sort by Memory, watch for increasing values
9. Network issues: Sort by Network I/O, look for zero values

Monitoring Best Practices

• Keep ECU Hardware Status visible at all times during testing
• Watch for status changes immediately after starting
• Monitor resource trends, not just instant values
• Correlate high resource usage with Console messages

Step 3: Analyze ECU Console Logs

The ECU Console panel is your window into the runtime behavior of all ECUs, aggregating log messages from across the system. Effective log analysis is crucial for understanding system behavior and diagnosing issues.

Understanding the ECU Console

1. Open the ECU Console panel
2. Located in the bottom panel area by default
3. Shows real-time log streaming from all running ECUs
4. Each log line includes timestamp, level, source, and message

Log Message Structure

Understanding log format helps you quickly parse information:

15:25:24.991  INF  Vcu  [00:04:13.213,000] e[0m<inf> s32k3_pedal_demo: ACCEL : status=0x01

Breaking down the components: - 15:25:24.991: System timestamp (your computer's time) - INF: Log level (INFO, WARNING, ERROR, DEBUG) - Vcu: Source ECU name - [00:04:13.213,000]: ECU internal timestamp (time since ECU started) - Message content: The actual log information

Filtering Logs by ECU

Filter to focus on specific ECUs:

1. Use the ECU dropdown filter:
2. Click the dropdown selector at the top of Console
3. Select a specific ECU (e.g., "VCU")

4. Only logs from that ECU are displayed

5. Or use text filtering:

6. Type the ECU name in the filter box
7. Logs are filtered in real-time

1. Clear filters to see all logs:
2. Click the X in the filter box
3. Or select "All ECUs" from dropdown

Filter by Log Level

Control which severity levels are visible:

1. Locate the log level buttons in the Console toolbar:
2. INFO (white): Normal operational messages
3. WARNING (yellow): Potential issues or unusual conditions
4. ERROR (red): Failures and critical problems

5. DEBUG (gray): Detailed diagnostic information

6. Common filtering strategies:

Focus on problems: - Uncheck INFO and DEBUG - Leave only WARNING and ERROR checked - Quickly identifies issues without noise

Detailed debugging: - Check all levels including DEBUG - Provides maximum information - Useful when investigating specific behaviors

Normal operation: - Check INFO and WARNING - Uncheck ERROR and DEBUG - Shows standard flow without clutter

Search and Navigate Logs

1. Search for specific terms:
2. Click in the search box or press Ctrl+F
3. Type keywords like error, timeout, CAN, init

4. Matching terms are highlighted throughout the log

5. Navigate search results:

6. Use Up/Down arrow keys to jump between matches
7. Match counter shows current position (e.g., "3 of 15")

8. Press Escape to clear search

9. Advanced search techniques:

10. Use partial words: time matches "timeout", "timer", "timestamp"
11. Case-insensitive by default
12. Combine with filters for precise results

Console Control Features

Pause and Resume: - Click Pause to freeze log scrolling - Useful when analyzing specific messages - New logs continue buffering in background - Click again to resume and see buffered messages

Clear Console: - Click Clear to remove all displayed logs - Doesn't affect ECU operation, only display - Useful to mark a point in time for testing

Auto-scroll: - Enabled (default): Automatically scrolls to show newest logs - Disabled: Stays at current position for inspection - Toggle with checkbox next to "Auto-scroll"

Export Logs for Analysis

1. Prepare logs for export:
2. Apply filters to include only relevant messages

3. Select appropriate time range

4. Click Export button in Console toolbar

5. Choose export format:

6. Plain Text (.txt):

   • Human-readable format with timestamps
   • Good for documentation and reports
   • Can be opened in any text editor

7. CSV (.csv):

   • Structured format for data analysis
   • Import into Excel or analysis tools
   • Columns: Timestamp, Level, ECU, Message

8. JSON (.json):

   • Machine-readable format
   • Useful for automated processing
   • Preserves all metadata

9. Save with descriptive filename:

10. Include date and test scenario
11. Example: 2024-01-15_vcu_test_logs.txt

Log Analysis Best Practices

• Start with ERROR level to identify critical issues first
• Use timestamps to correlate events across ECUs
• Export logs before stopping ECUs to preserve complete record
• Search for common error patterns: "fail", "error", "timeout", "invalid"
• Keep Console visible during all testing activities

Log Buffer Limits

The Console buffers up to 10,000 lines by default. In long-running tests: - Export logs periodically to avoid losing older messages - Use log level filtering to reduce noise - Consider implementing log rotation in production

Step 4: Track Resource Usage

The ECU Resource Monitor provides real-time visualization of system performance, helping you identify bottlenecks, detect memory leaks, and understand resource consumption patterns across your ECU network.

Agent Code Required

Resource monitoring data is collected by agent code that runs on the ECU and is built along with the ECU firmware. If the agent code is not included in your firmware build, the Resource Monitor will not display any data.

Understanding the Resource Monitor

1. Open the ECU Resource Monitor panel
2. Typically positioned in the center-right area
3. Shows dual graphs: CPU usage and Memory consumption
4. Each ECU has its own colored line for easy tracking

1. Graph components:

CPU Usage Graph (top): - Y-axis: Percentage (0-100%) - X-axis: Time - Each ECU shown in different color - Grid lines at 25%, 50%, 75% for reference

Memory Usage Graph (bottom): - Y-axis: Megabytes (MB) - X-axis: Time (synchronized with CPU graph) - Same color coding as CPU graph - Shows actual usage vs configured limits

Interpreting Performance Patterns

Understanding common patterns helps identify issues quickly:

Normal Patterns

• Flat lines at low values: ECUs idle, waiting for events
• Periodic small spikes: Regular processing cycles
• Synchronized spikes: ECUs responding to same event
• Stable memory: No leaks, consistent allocation

Problematic Patterns

• Sustained high CPU: Possible infinite loop or heavy processing
• Gradually increasing memory: Memory leak indication
• Sudden memory spike: Large allocation, may cause issues
• Erratic CPU jumping: Unstable processing or timing issues

Adjust Monitoring Window

1. Select time range from dropdown:

2. 1 minute: Capture immediate behavior and short spikes

3. 5 minutes: Recent activity and short-term patterns
4. 15 minutes: Medium-term trends and cycle detection
5. 30 minutes: Extended monitoring for stability

6. 1 hour: Long-term patterns and leak detection

7. When to use each range:

1-minute window: - Debugging immediate issues - Capturing transient spikes - Real-time response monitoring

5-15 minute windows: - Normal operation monitoring - Performance testing - Identifying patterns

30-60 minute windows: - Memory leak detection - Long-term stability testing - Thermal behavior analysis

Interactive Graph Features

Zoom and Pan

1. Zoom into specific time periods:
2. Click and drag horizontally to select time range
3. Graph zooms to show selected period in detail

4. Useful for analyzing specific events

5. Reset view:

6. Click Reset Zoom button to return to full range

7. Or double-click on graph area

8. Hover for details:

9. Move mouse over graph lines
10. Tooltip shows exact timestamp and value
11. Identifies which ECU at that point

Legend and Visibility

• Legend shows ECU color mapping
• Click ECU name in legend to toggle visibility
• Useful for focusing on specific ECUs
• Grayed-out names indicate hidden lines

Identifying Performance Issues

High CPU Usage Investigation

When CPU usage is consistently high:

1. Identify the ECU:
2. Note which colored line is elevated

3. Check legend for ECU name

4. Correlate with logs:

5. Switch to Console panel
6. Filter by that ECU

7. Look for processing messages

8. Check with Terminal:

9. Access ECU terminal
10. Run top to see process breakdown
11. Identify specific high-CPU processes

Memory Leak Detection

Signs of memory leaks:

1. Gradual increase pattern:
2. Memory line slopes upward over time
3. Doesn't plateau or decrease

4. Eventually reaches limit

5. Investigation steps:

6. Note rate of increase (MB per minute)
7. Export data for detailed analysis
8. Check Console for allocation messages

9. Use terminal for memory diagnostics

10. Terminal commands for memory analysis: ```bash # Check overall memory cat /proc/meminfo

# See per-process memory ps aux --sort=-%mem | head

# Monitor memory in real-time watch -n 1 free -m ```

Export Resource Data

1. Prepare for export:
2. Select appropriate time range

3. Ensure all relevant ECUs are visible

4. Click Export button and choose format:

CSV Format: - Timestamped data points - Columns: Time, ECU_Name, CPU%, Memory_MB - Import into Excel, Python, or R for analysis - Good for statistical analysis and trending

PNG Image: - Screenshot of current graph view - Includes legend and axes - Perfect for reports and documentation - Preserves visual patterns

1. Export best practices:
2. Name files with test scenario and timestamp
3. Export at regular intervals during long tests
4. Include both normal and problematic periods
5. Document any anomalies observed

Resource Baseline Establishment

Before testing: 1. Run system in idle state for 5 minutes 2. Export this as baseline data 3. Compare test results against baseline 4. Identifies abnormal resource consumption

Performance Monitoring Tips

• Set memory limits in ECU configuration to catch leaks early
• Use 1-minute window for immediate issues, 1-hour for leak detection
• Correlate resource spikes with Console timestamps
• Export data before stopping system to preserve complete record
• Create baseline measurements for comparison

Step 5: Monitor Network Traffic

The Network Traffic panel shows CAN messages in real-time.

View Live Messages

1. Open Network Traffic panel
2. Messages appear as they're transmitted
3. Columns show: Timestamp, ID, DLC, Payload, Channel, Source

Filter Messages

1. In filter bar, enter:
2. Message ID: 0x123 or 291 (decimal)
3. Channel: can0, can1
4. Source ECU: ECU name
5. Only matching messages are shown

Analyze Message Rates

1. Watch the Rate column (messages/second)
2. High rates may indicate excessive traffic
3. Zero rates might indicate a broken connection

View Signal Decoding

1. Load a DBC file: Project → Import Definitions
2. Signals are decoded and displayed below raw payload
3. Click message to see decoded signal values

Capture Traffic to Log

1. Configure capture first:
2. Click the Configure button in the toolbar
3. Select the network/channel to capture
4. Choose capture type and output format
5. Available formats: BLF (Vector), MDF4, CSV

1. Start recording:
2. Click Start Capture to begin recording

3. Traffic is recorded to the configured output

4. Stop and save:

5. Click Stop Capture when done
6. Capture file is saved to the configured location

Export Traffic Data

To export the current traffic view (not capture):

1. Click Export in the Network Traffic toolbar
2. Choose export format:
3. Text (.txt): Plain text format
4. CSV (.csv): Spreadsheet-compatible
5. JSON (.json): Structured data format
6. candump: Standard CAN log format

Step 6: Use Terminal Access

The Terminal panel provides direct shell access to ECU containers, enabling advanced debugging, system inspection, and real-time diagnostics. This powerful tool gives you command-line access to the Linux environment running inside each ECU.

Understanding Terminal Access

Terminal Only Available for Linux ECUs

Terminal access is only available for Linux-based ECUs (FSL Linux, Ubuntu). ECUs running RTOS firmware (FreeRTOS, Zephyr) do not support terminal access because these real-time operating systems do not include a shell environment.

If you followed the System Design Workflow tutorial with the Drive Cycle system, all ECUs (VCU, MCU, BMS) run Zephyr OS and will not have terminal access. Use the ECU Console logs and GDB debugging instead.

Requirements for terminal access: - Linux-based OS (FSL Linux, Ubuntu) - Debug mode enabled in ECU configuration - Container must have shell binaries installed

Connect to an ECU

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

3. Shows a dropdown selector at the top

4. Select an ECU from the dropdown:

5. Click the dropdown menu
6. Choose the target ECU (e.g., "VCU")

7. Terminal attempts connection automatically

8. Connection status indicators:

9. Connected: Shell prompt appears, ready for commands

10. Connecting: Terminal establishing connection
11. Failed: No shell available or ECU not running
12. Not Supported: ECU OS doesn't support terminal

Terminal Availability

The dropdown only shows ECUs with terminal support. If an ECU doesn't appear, it's likely running an RTOS without shell access.

Run Diagnostic Commands

Once connected, try these commands:

# Check CPU usage
top

# View memory info
cat /proc/meminfo

# List processes
ps aux

# Check network interfaces
ifconfig

# View recent log messages
dmesg | tail -20

# Check disk space
df -h

Search Terminal Output

1. Press Ctrl+F (Cmd+F on macOS)
2. Search box appears
3. Type search term
4. Matching text is highlighted
5. Use arrow keys to navigate matches

Terminal Actions

• Clear: Button clears terminal screen (history preserved)
• Copy: Select text with mouse, use Ctrl/Cmd+C
• Reconnect: If connection drops, click reconnect button

Warning

Some commands may require root privileges. Be cautious with system modifications.

Step 7: Troubleshoot Common Issues

Effective troubleshooting requires systematic use of multiple monitoring panels to correlate symptoms with root causes. Here's how to diagnose and resolve common issues.

ECU Not Starting

Symptoms: ECU shows red error state or remains in stopped state

Investigation steps:

1. Check ECU Hardware Status panel:
2. Look for red error indicator

3. Note the exact error state shown

4. Examine Console logs:

5. Filter to the specific ECU
6. Look for ERROR level messages during startup

7. Common errors: "Image not found", "Port conflict", "Resource limits"

8. Verify configuration:

9. Return to System Canvas
10. Select the problematic ECU

11. Check Properties panel for:

    • Valid firmware path (if specified)
    • Adequate memory allocation (minimum 128MB)
    • Correct board selection

12. Check Docker status:

13. Verify Docker Desktop is running
14. Check available resources in Docker settings
15. Ensure no conflicting containers

Solutions: - Increase memory allocation in ECU properties - Verify firmware binary exists at specified path - Restart Docker Desktop if connection issues - Check host system resources aren't exhausted

High Resource Usage

Symptoms: ECU consuming excessive CPU or memory

Investigation process:

1. Identify the culprit in Resource Monitor:
2. Note which ECU line is elevated
3. Check if it's CPU, memory, or both

4. Observe if it's constant or periodic

5. Correlate with Console messages:

6. Filter logs to high-usage ECU
7. Look for processing or allocation messages

8. Check for error loops or repeated failures

9. Deep dive with Terminal (if available): ```bash # Real-time process monitor top

# Detailed process list ps aux --sort=-%cpu | head -10

# Memory breakdown cat /proc/meminfo

# Check for zombie processes ps aux | grep defunct ```

1. Analyze patterns:
2. Sudden spike: Likely processing event
3. Gradual increase: Possible memory leak
4. Oscillating: Normal cyclic behavior
5. Sustained high: Potential infinite loop

Solutions: - Set resource limits in ECU configuration - Review firmware code for inefficiencies - Check for proper cleanup in cyclic tasks - Implement rate limiting for message processing

Memory Leak Detection

Symptoms: Gradually increasing memory usage over time

Detailed investigation:

1. Establish baseline:
2. Run system for 5 minutes idle
3. Note starting memory usage

4. Calculate rate of increase (MB/minute)

5. Long-term monitoring:

6. Set Resource Monitor to 1-hour view
7. Export data every 15 minutes

8. Plot trend line in spreadsheet

9. Terminal diagnostics: ```bash # Track memory over time while true; do date free -m | grep Mem sleep 60 done

# Find growing processes ps aux --sort=-%mem | head -5 ```

1. Log correlation:
2. Search Console for "malloc", "new", "alloc"
3. Look for allocation without corresponding free
4. Check for growing data structures

Prevention: - Implement proper RAII in C++ code - Use memory profiling tools during development - Set memory limits to catch leaks early - Regular heap analysis in firmware

Network Communication Issues

Symptoms: No CAN messages visible or ECUs not communicating

Systematic diagnosis:

1. Verify physical topology:
2. Open System Canvas
3. Confirm ECUs connected to same network bus

4. Check network configuration (baud rate, channel)

5. Check Network Traffic panel:

6. Clear all filters
7. Verify correct bus selected

8. Look for any traffic at all

9. Console investigation:

10. Search for "CAN", "network", "init" messages
11. Look for initialization failures

12. Check for "No such device" errors

13. Terminal network diagnostics: ```bash # Check CAN interface ip link show can0

# Verify interface is up ifconfig can0

# Monitor CAN traffic directly candump can0

# Check for errors ip -details link show can0 ```

Common causes and solutions: - Wrong baud rate: Ensure all ECUs use same rate - Interface down: Run ip link set can0 up - No firmware sending: Verify ECU code includes CAN transmission - Filter hiding messages: Clear all panel filters

Terminal Connection Problems

Symptoms: Terminal won't connect or shows "Not Supported"

Troubleshooting steps:

1. Verify ECU compatibility:
2. Terminal only works with Linux-based OS (FSL Linux, Ubuntu)
3. RTOS ECUs (FreeRTOS, Zephyr) do not support terminal

4. The Drive Cycle tutorial ECUs (VCU, MCU, BMS) run Zephyr - use Console logs or GDB instead

5. Check ECU state:

6. Must show "Running" in ECU Hardware Status

7. Wait 10-15 seconds after start for initialization

8. Enable debug mode:

9. Select ECU in System Canvas
10. In Properties, check "Enable" under DEBUG

11. Apply changes and restart ECU

12. Container verification:

13. Some containers lack shell binaries
14. Check image documentation for shell support
15. May need custom image with debug tools

Alternative debugging methods for RTOS ECUs: - Use ECU Console logs for runtime debugging - Enable GDB debugging in ECU properties (see System Design Workflow tutorial) - Add debug print statements to firmware code - Use JTAG/SWD for hardware-level debugging

Step 8: Export and Analyze Monitoring Data

Exporting monitoring data is crucial for documentation, analysis, and sharing results with team members. TrueFidelity provides comprehensive export capabilities across all monitoring panels.

Create Monitoring Report

Build a complete diagnostic report by exporting data from each panel:

1. Export from each monitoring panel:

ECU Console exports: - Format: Text (.txt) for reports, CSV for analysis - Content: Filtered or complete log history - Naming: [date]_[test]_console_log.txt

Resource Monitor exports: - Format: CSV for data analysis, PNG for visual reports - Content: Time-series CPU and memory data - Naming: [date]_[test]_resources.csv

Network Traffic exports: - Format: Text, CSV, JSON, or candump for traffic view - Format: BLF, MDF4, CSV for capture recordings - Content: CAN frames with timestamps - Naming: [date]_[test]_can_traffic.csv

Terminal session exports: - Copy important command outputs - Save as text files for reference - Include system state snapshots

1. Combine into comprehensive report:
2. Executive summary with key findings
3. Performance graphs from Resource Monitor
4. Critical log excerpts from Console
5. Network traffic analysis
6. Recommendations and next steps

Automated Data Collection Strategy

For long-duration tests, implement systematic data collection:

1. Pre-test setup:
2. Clear all panels for clean start
3. Set Resource Monitor to appropriate time window
4. Start Network Traffic capture if needed

5. Document test parameters

6. During test execution:

7. Export Console logs every 30 minutes
8. Capture Resource Monitor data at milestones
9. Save Network Traffic during critical events

10. Document observations in real-time

11. Post-test collection:

12. Final export of all panels
13. Screenshot any anomalies
14. Save complete terminal history
15. Archive all data with test documentation

Data Analysis Workflow

Transform raw exports into actionable insights:

1. Import into analysis tools: ```python # Python example for resource analysis import pandas as pd import matplotlib.pyplot as plt

# Load exported CSV df = pd.read_csv('resources.csv')

# Plot memory trends df.plot(x='timestamp', y='memory_mb') plt.title('Memory Usage Over Time') plt.show() ```

1. Correlation analysis:
2. Match Console timestamps with resource spikes
3. Correlate network traffic with CPU usage

4. Identify patterns and anomalies

5. Generate reports:

6. Use exported PNGs in presentations
7. Create trend graphs from CSV data
8. Document findings with evidence

Best Practices for Effective Monitoring

Organize Panels by Workflow

Development workflow: - Focus: System Canvas, Properties, Build Console - Monitor: ECU Hardware Status for deployment verification

Performance monitoring workflow: - Focus: ECU Resource Monitor, Task Monitor - Support: Console for correlation, Terminal for deep dive

Debugging workflow: - Focus: ECU Console with filters, Terminal - Support: Resource Monitor for performance impact

Network analysis workflow: - Focus: Network Traffic, Signal Viewer - Support: Signal Chart for visualization

Use Filters Strategically

Effective filtering principles:

• Start broad, then narrow down
• Don't over-filter initially - you might miss context
• Save common filter combinations
• Use multiple panels with different filters

Common filter patterns:

• Problem investigation: ERROR + WARNING only
• Performance analysis: Specific ECU + all levels
• Network debugging: CAN ID range + timestamp window
• Integration testing: Multiple ECUs + INFO level

Export Best Practices

Regular export schedule:

• Every 30 minutes for long tests
• At each test milestone
• Before configuration changes
• After observing anomalies

File organization:

TestResults/
├── 2024-01-15_VCU_Test/
│   ├── console_logs/
│   │   ├── startup_console.txt
│   │   ├── runtime_console.txt
│   │   └── shutdown_console.txt
│   ├── resources/
│   │   ├── baseline_resources.csv
│   │   ├── load_test_resources.png
│   │   └── memory_leak_analysis.csv
│   └── network/
│       ├── can_traffic.csv
│       └── message_analysis.csv

Establish Performance Baselines

1. Create baseline measurements:
2. Run system idle for 10 minutes
3. Export all metrics

4. Document normal ranges

5. Use baselines for comparison:

6. Overlay test results on baseline
7. Calculate deviation percentages

8. Identify abnormal behaviors

9. Update baselines regularly:

10. After firmware changes
11. When configuration updates
12. For different test scenarios

Advanced Monitoring Techniques

Multi-Panel Correlation

Synchronize multiple panels for comprehensive analysis:

1. Time-based correlation:
2. Note timestamp of interest in one panel
3. Jump to same time in other panels

4. Build complete picture of system state

5. Event-driven analysis:

6. Identify trigger event in Console
7. Check Resource Monitor at that time
8. Verify Network Traffic patterns
9. Investigate with Terminal if needed

Performance Profiling

Systematic approach to performance optimization:

1. Baseline profiling:
2. Measure idle resource usage
3. Document startup sequence timing

4. Establish normal operating ranges

5. Load testing:

6. Apply increasing load
7. Monitor resource scaling

8. Identify bottlenecks

9. Optimization validation:

10. Compare before/after metrics
11. Verify improvements
12. Check for regression

Conclusion

You've now mastered TrueFidelity's comprehensive monitoring capabilities. These skills enable you to:

• ✅ Set up optimized monitoring layouts
• ✅ Track ECU health and resource usage
• ✅ Analyze logs effectively with filtering
• ✅ Identify performance issues and memory leaks
• ✅ Debug using terminal access
• ✅ Export and analyze monitoring data
• ✅ Troubleshoot common issues systematically

Next Steps

Immediate actions: 1. Practice with your own ECU systems 2. Create custom layouts for your workflow 3. Build a library of baseline measurements 4. Develop standard troubleshooting procedures

Advanced learning: - Explore CAN Log Analysis for network protocol debugging - Master Signal Analysis for data interpretation - Study Performance Optimization techniques - Learn Automated Testing integration

Additional resources: - System Design Workflow: Build complete ECU systems - Workspaces & Layouts: Customize your environment - Reference Guide: Detailed feature documentation - Troubleshooting Guide: Solutions for complex issues

Monitoring Mastery

Effective monitoring is the foundation of reliable ECU development. Regular practice with these tools and techniques will make you proficient at identifying and resolving issues quickly, leading to more robust and performant automotive systems.