Tools, traces & logs

The JD mentions "simulation tools for vehicle signals", "logs, traces and evidence" and "trace/log analysis". This chapter explains each tool in plain words and teaches you to read traces and logs, with exercises.

Your toolbox at a glance

Vector CANoe: the signal simulator

The parts of CANoe you'll use

CANalyzer is its smaller sibling: mainly for watching, analysing and recording the bus, with limited simulation.

CAPL: CANoe's scripting language

CAPL looks like the C language. It is event-driven: you write "when this happens, do that" (on key press, on message received, on timer).

variables {
  msTimer rampTimer;          // a timer in milliseconds
  float temp = 6.0;
}

on key 'r' {                  // press 'r' to start the ramp
  temp = 6.0;
  setTimer(rampTimer, 2000);
}

on timer rampTimer {          // every 2 s: lower the temperature by 0.1
  temp = temp - 0.1;
  $Outside_Temp = temp;       // set the signal value
  write("Outside_Temp = %.1f", temp);
  if (temp > 3.85) setTimer(rampTimer, 2000);
}

on message Ambient_Info {     // whenever this message is on the bus
  write("Raw byte 0 = 0x%02X", this.byte(0));
}

This script does the BVA "falling" test automatically: 6.0 → 5.9 → … → 3.9 °C, with 2 s at each value, while you watch the cluster.

Reading a CAN trace

A trace is a recording of the bus. In text form (.asc) it looks like this:

date Wed Sep 30 10:15:00.000 am 2026
base hex  timestamps absolute
   31.920000 1  3A5             Rx   d 8 5C 00 00 00 00 00 00 00
   32.020000 1  1F0             Rx   d 8 88 13 00 00 00 00 00 00
   32.120000 1  3A5             Rx   d 8 5A 00 00 00 00 00 00 00
   32.220000 1  3A5             Rx   d 8 5A 00 00 00 00 00 00 00

ECU logs: DLT and DLT Viewer

Index  Time                     ECU   App   Ctx   Level  Payload
10231  2026/09/30 10:15:32.124  CLU1  HMI   TEMP  info   OutsideTemp=5.0 IceWarning active=1
10232  2026/09/30 10:15:32.130  CLU1  HMI   GFX   debug  Icon snowflake visible
10240  2026/09/30 10:15:40.010  HU01  MED   USB   error  Mount failed: /dev/sda1 not found
10241  2026/09/30 10:15:40.012  HU01  MED   PLY   warn   No playable source, switching to radio

How you use DLT Viewer: connect to the ECU (usually over Ethernet, default TCP port 3490) or open a saved .dlt file; add filters (only App ID "HMI", only level error and above); search text; set markers at important moments; export the relevant part and attach it to the ticket.

Android head units: ADB and logcat

Many new head units run Android Automotive OS. There you use ADB (Android Debug Bridge), a command-line tool, and logcat, the Android log.

Logcat levels: Verbose, Debug, Info, Warning, Error, Fatal. Important keywords: FATAL EXCEPTION (an app crashed), ANR (Application Not Responding = frozen), tombstone (native crash).

Log analysis: the method

1. Find the exact failure timeFrom the video, the Robot log timestamp, or your notes.
2. Align the clocksPC time, ECU time and video time may differ by seconds. Find one known event in all of them (e.g. ignition on) to align.
3. Open trace and logs around that time±30 seconds is a good window.
4. Check the inputIn the CAN trace: did the expected signal really arrive with the right value?
5. Check the reactionIn the ECU log: was the input received? What was decided? Any error, exception, crash, restart, timeout?
6. Compare with a passing runWhat is different?
7. Write down the story and attach evidencePut the key lines and timestamps in the ticket; attach the trimmed files and keep the originals.

Search keywords: error, fail, exception, fatal, crash, abort, timeout, reset, restart, watchdog, not found, invalid, SNA, overflow.

Diagnostics and flashing tools

• Read and clear DTCs before and after tests (see chapter 2).
• Read the software version to confirm the right build is on the bench.
• Flashing (installing a build): with a flashing tool (e.g. Vector vFlash), the OEM's tool, a USB update, or a customer script. After flashing: check the version and do a smoke test.

Test management & traceability tools

Evidence: good habits

• Name files clearly: IVI-1433_TC-TEMP-003_24.3.1_B03_video.mp4.
• Keep trace and video running while testing so you never miss a rare bug.
• Screenshot the problem with the software version visible if possible.
• Store originals; attach trimmed parts to tickets.

Remote benches

• Access through VPN + remote desktop to the bench PC.
• A webcam points at the screens; a video grabber captures the display output.
• A remote power switch / relay box lets you power-cycle and switch ignition.
• Etiquette: book bench time, don't change configuration without telling others, leave the bench in a clean state, report hardware problems to the local team.

Bench health checklist (before every run)

• ☐ Correct build flashed and version checked
• ☐ Power supply voltage correct (e.g. 13.5 V), relay box working
• ☐ CANoe configuration and DBC version match the build
• ☐ Phones charged, paired as needed; USB sticks with test data plugged in
• ☐ Logging on: trace, DLT/logcat, video
• ☐ DTCs cleared
• ☐ Smoke test passed