AutoST für Prüflabore: Eine wiederholbare Baseline für jedes Kundensteuergerät

Die Aufgabe

Ein unabhängiges Prüflabor testet Steuergeräte, die es nicht gebaut hat, für Kunden, die eine zweite Meinung, einen Validierungstest oder einen Nachweis wollen, den ein OEM akzeptiert. Jede Woche kommt ein anderes Steuergerät an: ein Karosserie-Steuergerät von einem Zulieferer, ein On-Board-Charger von einem anderen, eine Infotainment-Headunit von einem dritten. Jedes bringt einen anderen Diagnose-Stack mit, eine andere Beschreibungsdatei oder gar keine, und ein festes Budget an Tagen.

Das Labor verkauft Expertise, aber ein großer Teil jedes Auftrags ist keine Expertenarbeit. Prüfstand verkabeln, Diagnoseadressen finden, jede Session nach erreichbaren Services absuchen, ein paar tausend Seeds sammeln und die antwortenden Services fuzzen: Das ist auf jedem Ziel dieselbe Prozedur. Bei den Steuergeräte- und Infotainment-Penetrationstests unseres Teams hat diese Prozedur regelmäßig einen großen Teil der ersten Tage gekostet, bevor jemand auf Firmware oder Hardware geschaut hat. Labore, die das selbst skripten, haben am Ende einen Ordner voller Werkzeuge, die nur ein Ingenieur versteht.

Was die Rolle aus einem Testlauf braucht

Ein Labor braucht eine Baseline, die über alle Kunden gleich ist, als Methode dokumentiert ist und früh im Auftrag fertig wird.

• Dieselbe Prozedur auf jedem Ziel. UDS-Enumeration von Sessions, Services, Sub-Funktionen und DIDs, SecurityAccess-Prüfung (0x27) auf Zufälligkeit der Seeds, Fehlversuchszähler, Verzögerungen und bekannte schwache Algorithmen, dazu Seeded UDS- und CAN-Fuzzing mit Crash- und Hang-Erkennung. Ein Profil unter der Änderungskontrolle des Labors, damit zwei Ingenieure an zwei Steuergeräten vergleichbare Ergebnisse liefern.
• Abdeckung der Netze, die Kunden mitbringen. UDS über DoIP, DoIP-Gateway-Routing und SOME/IP-Service-Tests für Ethernet-Steuergeräte, Android-IVI-Härtungschecks über ADB für Headunits, CAN oder CAN FD für alles andere.
• Reproduzierbarkeit für Streitfälle. Ein gespeicherter Seed pro Fuzzing-Lauf und der exakte Request hinter jedem Finding. Wenn ein Zulieferer “nicht reproduzierbar” sagt, spielt das Labor den Frame nach.
• Trennung der Kunden. Gruppen und rollenbasierter Zugriff pro Kunde, und die Wahl, die ganze Installation auf den eigenen Servern des Labors zu betreiben.
• Ausgaben, auf denen der Bericht aufbaut. Ein PDF pro Scan mit datierter Historie, SARIF für Kunden, die Findings in ihren Werkzeugen wollen, und ein Fix Plan mit Was, Risiko und Fix pro Finding.

Was ein Labor von AutoST nicht bekommt, ist der Expertenteil. AutoST reversed keine Firmware, glitcht keinen Mikrocontroller und verkettet keine Findings über mehrere Steuergeräte. FlexRay, LIN und HSFZ testet es ebenfalls nicht.

Typisches Setup

Labore installieren AutoST fast immer als Container auf eigenen Servern im Labornetz. Jeder Prüfstand bekommt einen Carbyne-Agenten: unter Windows mit Vector-Hardware über die XL Driver Library oder unter Linux mit PEAK, Kvaser oder jedem anderen SocketCAN-Interface, dazu Ethernet für DoIP, SOME/IP und ADB. Der Agent pollt das Backend über HTTPS, im Prüfstandsnetz werden keine eingehenden Ports geöffnet, und mehrere Prüfstände scannen parallel.

Jeder Kunde wird eine Gruppe. Die Laborleitung besitzt die Testprofile und die Risikogewichtung, Testingenieure fahren die Baseline an ihren Prüfständen, und die Experten setzen bei den Findings an. Lizenziert wird pro getesteter Komponente, der Preis kommt nach einer Demo; wie das zu einer wechselnden Kundenliste passt, klären wir in diesem Gespräch.

Ein sinnvolles erstes Projekt

Lass AutoST neben einem Auftrag laufen, den du sowieso machst, dann ist der Vergleich ehrlich.

1. Woche 1: Setup. Backend auf einem Laborserver installieren, Agenten an zwei Prüfständen koppeln, eine Gruppe für einen Kunden anlegen und die ODX- oder CDD-Datei importieren, falls der Kunde eine geliefert hat.
2. Woche 2: Parallele Baseline. Am Kundensteuergerät fährt AutoST Enumeration, DID- und Routinen-Scan und SecurityAccess-Prüfung, während deine Ingenieure wie gewohnt arbeiten. Vergleiche, was jeder gefunden hat und wie lange es gedauert hat.
3. Woche 3: Fuzzing. Seeded UDS-Fuzzing auf den Services, die das Steuergerät anbietet, mit TesterPresent-Lebenszeichen und DTC-Überwachung, und CAN-Fuzzing, wo der Kunde es beauftragt hat. Jeden Crash einmal reproduzieren.
4. Woche 4: Bericht. Das Kundendeliverable auf dem AutoST-PDF und dem SARIF-Export aufbauen, die manuellen Findings ergänzen und die gesparte Zeit festhalten.
5. Entscheidung. Die Baseline in die Methodenbeschreibung aufnehmen und festlegen, welche Auftragsarten mit ihr starten.

Wie Ergebnisse in ISO/SAE 21434 und UN R155 fließen

Ein Laborbericht ist Nachweis im Work Product eines anderen, er muss also Methode, Umfang und Datum zeigen. ISO/SAE 21434:2021 Clause 10.4.2 fordert die Verifikation der Implementierung gegen die Cybersecurity-Spezifikation ([RQ-10-09]) und empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans ([RC-10-12]); die AutoST-Baseline ist genau dieser Komponententest, jedes Mal gleich ausgeführt. Clause 11 ([RQ-11-01]) nennt Penetrationstests für die Validierung; dort ergänzen die Experten des Labors, was kein Werkzeug leistet.

UN R155 Anhang 5 listet Bedrohungen wie unautorisierten Zugriff auf die Diagnose und Manipulation über Fahrzeugnetze, und der Hersteller muss zeigen, dass die Maßnahmen wirken. Ein datierter, reproduzierbarer Scan pro Steuergerät ist ein Nachweis, dem ein Technischer Dienst folgen kann. Labore, die nach ISO/IEC 17025 arbeiten, brauchen außerdem dokumentierte, wiederholbare Methoden und nachvollziehbare Aufzeichnungen; ein festes AutoST-Profil mit gespeichertem Seed pro Lauf hilft dabei, die Akkreditierung bleibt aber Arbeit des Labors. AutoST stellt keine Zertifikate aus und macht nichts konform.