CAN-Interface für ECU-Security-Tests wählen

Das CAN-Interface zwischen deinem Test-Host und dem ECU entscheidet, was du sehen und senden kannst, es lohnt sich also, bewusst zu wählen statt zu nehmen, was in der Schublade liegt. Für Security-Tests zählen andere Dinge als für gewöhnliche Diagnostik: Timing-Kontrolle, CAN FD, Error-Frame-Sicht und Treiberstabilität ändern alle, was ein Scan oder ein Fuzz-Lauf kann. Dieser Leitfaden behandelt, worauf du achten solltest und womit AutoST arbeitet, und versucht fair zu Hardware zu sein, die du vielleicht schon besitzt.

Was Security-Tests von einem Interface verlangen

Gewöhnliche Diagnostik muss meist wohlgeformte Requests senden und Antworten lesen. Security-Tests fordern mehr:

• Korrektes Timing. ISO-TP-Flow-Control (ISO 15765-2) und UDS-P2/P2*-Timing hängen davon ab, dass das Interface Frames pünktlich liefert. Ein Interface mit hoher oder schwankender Latenz verursacht falsche Timeouts, die wie Findings wirken, obwohl sie keine sind.
• CAN FD. Nutzt ein ECU CAN FD (ISO 11898-1), brauchst du ein Interface, das FD-Frames mit der richtigen Data-Phase-Bitrate sendet und empfängt, sonst erreichst du diese Nachrichten schlicht nicht.
• Error-Frame-Sicht. Fuzzing und Malformed-Frame-Tests profitieren davon, Bus-Fehler und Fehlerzähler zu sehen, nicht nur saubere Frames. Nicht jedes Interface legt sie offen.
• Präzise Zeitstempel. Ein Fuzzing-Finding zu reproduzieren ist leichter, wenn Frames genaue Hardware-Zeitstempel tragen.
• Konfigurierbare Bitrate und Sample Point. Du musst den Bus exakt treffen; ein Default, der nah dran, aber nicht richtig ist, verursacht sporadische Fehler, die Stunden kosten.
• Stabile Treiber. Ein langer Fuzzing-Lauf, der Frames verliert oder den Adapter zurücksetzt, ist schlimmer als nutzlos, weil er Findings erzeugt, die in Wahrheit Treiber-Aussetzer sind.

Die wichtigsten Optionen

Interface-Familie	OS	CAN FD	Stärken	Abwägungen
SocketCAN (PEAK, Kvaser, andere)	Linux	Ja, hardwareabhängig	Offen, skriptbar, exzellentes Tooling, breite Hardware-Unterstützung	Nur Linux; Funktionen je nach Adapter und Treiber
Vector (VN-Serie)	Windows	Ja	Präzises Timing, starkes Ökosystem, im Automotive gut unterstützt	Kosten; an die XL Driver Library unter Windows gebunden
comma.ai Panda	Windows, Linux	Ja	Günstig, portabel, gut für den Einstieg	Weniger Low-Level-Funktionen als professionelle Hardware
Andere professionelle Interfaces	Variiert	Variiert	Kann zu einem bestimmten Laboraufbau passen	Prüfe, ob dein Tooling einen Treiberpfad hat

SocketCAN verdient eine Anmerkung, weil es kein Gerät ist, sondern ein Kernel-Interface. Jeder CAN-Adapter mit einem Linux-SocketCAN-Treiber, PEAK und Kvaser unter vielen anderen, präsentiert dasselbe can0-artige Interface, was Skripting und Tooling unabhängig von der darunterliegenden Hardware einheitlich macht.

Wie AutoST sich verbindet

Der Bench-Agent von AutoST, Carbyne, arbeitet mit SocketCAN unter Linux (also jedem Interface mit Linux-Treiber, inklusive PEAK und Kvaser), Vector-Hardware unter Windows über die XL Driver Library und dem comma.ai Panda auf beiden. Er erkennt ein angeschlossenes Interface automatisch oder lässt dich eines wählen, und Bitrate, CAN-FD-Data-Bitrate und Sample Point sind alle konfigurierbar, sodass der Agent deinen Bus trifft statt einen Default zu erzwingen. Der Agent läuft unter Windows oder Linux, das Dashboard im Browser.

Besitzt du schon ein professionelles Interface, das nicht in dieser Liste steht, lohnt eine kurze Prüfung statt einer Annahme: unter Linux funktioniert es, wenn es einen SocketCAN-Treiber hat. Das deckt einen großen Teil der Hardware ab, die ohnehin an Prüfständen hängt.

Eines für deinen Prüfstand wählen

Ein praktischer Weg zu entscheiden:

1. Zum Test-OS passen. Ist dein Prüfstand Linux, gibt dir SocketCAN die breiteste Hardware-Wahl und das beste Skripting. Ist es Windows und du hast Vector-Hardware, ist der XL-Pfad gut ausgetreten.
2. CAN FD bestätigen. Prüfe, ob ein Ziel-ECU CAN FD nutzt und mit welcher Data-Phase-Bitrate, und stelle sicher, dass das Interface es unterstützt.
3. Entscheiden, wie Low-Level du gehst. Für Diagnostik, Enumeration und ISO-TP-Fuzzing reicht ein verlässliches Mittelklasse-Interface. Für Error-Frame-Analyse und enges Timing verdient die höherwertige Hardware ihre Kosten.
4. Für Stabilität kaufen, nicht für Funktionen, die du nicht nutzt. Eine lange Fuzzing-Kampagne braucht ein Interface, das über Stunden keine Frames verliert, was mehr zählt als eine exotische Funktionsliste.

Die ehrliche Antwort zu den Kosten

Du brauchst nicht das teuerste Interface, um die meisten ECU-Schwächen zu finden. Schwacher SecurityAccess, in der falschen Session erreichbare Services und schreibbare Identifikations-DIDs zeigen sich alle über einen verlässlichen Mittelklasse-Adapter mit korrektem Timing. Die High-End-Hardware zahlt sich aus, wenn du präzise Zeitstempel, Error-Frame-Sicht und FD mit hohen Data-Phase-Bitraten brauchst. Passe das Interface an die Arbeit an, nicht das Budget an die Marke, und stelle sicher, dass dein gewähltes Gerät einen sauberen Treiberpfad auf dem OS deines Prüfstands hat.