AutoST for Test Labs: One Repeatable Baseline for Every Client ECU

The job

An independent test lab tests ECUs it did not build, for clients who want a second opinion, a validation test or evidence an OEM will accept. Every week a different ECU arrives: a body controller from one supplier, an on-board charger from another, an infotainment head unit from a third. Each comes with a different diagnostic stack, a different description file or none at all, and a fixed budget of days.

The lab sells expertise, but a large share of every engagement is not expert work. Wiring the bench, finding the diagnostic addresses, walking every session for reachable services, collecting a few thousand seeds and fuzzing the services that answer is the same procedure on every target. When our team ran ECU and infotainment penetration tests, that procedure regularly ate a large share of the first days before anyone looked at firmware or hardware. Labs that script it themselves end up with a folder of tools that only one engineer understands.

What the role needs from a test run

A lab needs a baseline that is identical across clients, documented as a method and finished early in the engagement.

• The same procedure on every target. UDS enumeration of sessions, services, sub-functions and DIDs, SecurityAccess (0x27) checks for seed randomness, attempt counters, delays and known weak algorithms, and seeded UDS and CAN fuzzing with crash and hang detection. One profile, kept under the lab’s change control, so two engineers testing two ECUs produce comparable results.
• Coverage of the networks clients bring. UDS over DoIP, DoIP gateway routing and SOME/IP service testing for Ethernet ECUs, Android IVI hardening checks over ADB for head units, and CAN or CAN FD for everything else.
• Reproducibility for disputes. A stored seed per fuzzing run and the exact request behind each finding. When a supplier says “cannot reproduce”, the lab replays the frame.
• Client separation. Groups and role-based access per client, and the choice to run the whole installation on the lab’s own servers.
• Output the lab can build its report on. A PDF per scan with a dated history, SARIF for clients who want findings in their tooling, and a Fix Plan with what, risk and fix per finding.

What a lab does not get from AutoST is the expert part. AutoST does not reverse firmware, glitch a microcontroller or chain findings across ECUs. It also does not test FlexRay, LIN or HSFZ.

Typical setup

Labs almost always install AutoST as a container on their own servers, inside the lab network. Each test bench gets a Carbyne agent: on Windows with Vector hardware through the XL driver library, or on Linux with PEAK, Kvaser or any other SocketCAN interface, plus Ethernet for DoIP, SOME/IP and ADB. The agent polls the backend over HTTPS, so the bench network needs no inbound ports, and several benches run scans in parallel.

Each client becomes a group. The lab lead owns the test profiles and the risk weighting, test engineers run the baseline on their benches, and the experts pick up from the findings. Licensing is per tested component, quoted after a demo; how that maps to a lab’s changing client list is part of that conversation.

A sensible first project

Run AutoST next to an engagement you are doing anyway, so the comparison is honest.

1. Week 1: setup. Install the backend on a lab server, pair agents on two benches, create a group for one client and import the ODX or CDD file if the client supplied one.
2. Week 2: parallel baseline. On the client ECU, let AutoST run enumeration, the DID and routine scan and the SecurityAccess checks while your engineers work as they normally would. Compare what each found and how long it took.
3. Week 3: fuzzing. Seeded UDS fuzzing on the services the ECU exposes, with TesterPresent liveness and DTC monitoring, and CAN fuzzing where the client asked for it. Reproduce every crash once.
4. Week 4: report. Build the client deliverable on the AutoST PDF and SARIF export, add the manual findings and note the time saved.
5. Decision. Write the baseline into your method description and decide which engagement types start with it.

How results feed ISO/SAE 21434 and UN R155

A lab report is evidence in someone else’s work product, so it has to show method, scope and date. ISO/SAE 21434:2021 Clause 10.4.2 requires verification of the implementation against the cybersecurity specification ([RQ-10-09]) and recommends component testing with fuzz testing and vulnerability scanning ([RC-10-12]); the AutoST baseline is that component testing, run the same way every time. Clause 11 ([RQ-11-01]) names penetration testing for validation; that is where the lab’s experts add what no tool does.

UN R155 Annex 5 lists threats such as unauthorised access to diagnostics and manipulation over vehicle networks, and the manufacturer has to show the mitigations work. A dated, reproducible scan per ECU is evidence a technical service can follow. Labs working under ISO/IEC 17025 also need documented, repeatable methods and traceable records; a fixed AutoST profile with a stored seed per run helps with that, but the accreditation stays the lab’s own work. AutoST issues no certificates and does not make anything compliant.