ISO 16750-2 electrical tests: what the standard covers and how to automate them

ISO 16750-2 defines the electrical-load tests for road-vehicle electronics: supply voltage range, overvoltage, superimposed AC, slow ramps, drops and interruptions, reset behavior, starting profiles, load dump, reversed voltage, ground offset, open circuits, short circuits and insulation. A list-mode programmable supply runs the slow profiles from a script. Load dump and fast transients need dedicated generators.

The current edition is ISO 16750-2:2023, edition 5, published in July 2023 at 34 pages, according to ISO's page for the standard. The full text is sold, so this guide uses public sources: ISO's pages, the Swedish Institute for Standards' preview of the identical SS-ISO 16750-2:2023, Texas Instruments documents, and Keysight's N6700 programmer's reference for the code. Where the preview stops, use your licensed copy.

What does ISO 16750-2 cover?

ISO 16750-2 is part 2 of a series on environmental testing of electrical and electronic equipment in road vehicles. Its scope, per ISO and the SIS preview:

• It describes electrical loads on electric and electronic systems and components for road vehicles.
• It excludes motorcycles and mopeds, and does not cover electromagnetic compatibility (EMC).
• Electrical loads do not depend on mounting location, but can vary with the impedance of the wiring harness and connection system, "including both the resistance and the inductance." The 2012 edition's abstract named only resistance.
• Systems released for production or in development before July 2023 can be exempted from the edition's changes.

Part 2 leans on part 1. ISO 16750-1:2023 holds the terminology and general requirements for the series, and part 2 points to it for the operating modes, the functional status classes that define a pass, the supply voltage UA, and Tmin and Tmax. It cites part 4 for operating temperature ranges.

The preview's table of contents lists every test. The equipment column is a bench-planning aid, not part of the standard.

What changed in ISO 16750-2:2023?

The fifth edition's foreword lists these main changes from 2012:

• Operating modes are now used for the electrical tests, and redundant supplies are handled for the relevant test cases.
• Two tests are new: transient overvoltage and micro interruption in supply voltage.
• The superimposed alternating voltage test was updated completely, including a new test method and a frequency range extended to 200 kHz.
• The DC supply voltage, jump start, slow decrease and increase, reset behavior, reversed voltage, and ground reference and supply offset tests are specified in more detail, and the starting profile test explains its severity levels.
• Single line interruption splits into a static case (one interruption) and a dynamic case (bursts of interruptions).
• Short circuit protection became short circuit/overload protection, with a new test case for overloading load circuits.
• Annex B describes the origin of the load dump pulse in more detail.

If your test plan was written against the 2012 edition, the new tests, the AC frequency range and the redundant-supply combinations are the first places to check.

What supply voltage ranges does ISO 16750-2 define?

Clause 4.2 checks that the equipment works at its minimum and maximum supply voltage, and its tables assign each device a code:

The profile's timing parameters are t1 = 30 s and t2 = 60 s, with rise and fall rates of 1 V/s. It runs in operating modes 3.3 and 3.4, which together cover minimum and maximum load, at both Tmin and Tmax, and once more at room temperature in mode 3.2, normal loading. A DUT with redundant supplies is tested at every combination of USmin and USmax across its supply inputs. The requirement is functional status class A, as part 1 defines it, during active operating modes.

Clause 4.1 sets defaults that every test inherits:

• Tolerances of ±5% on frequency and time, ±0.2 V on voltage, ±2% on current, and ±10% on inductance and resistance.
• Voltage curves are drawn without load, and unless otherwise specified, voltages are measured at the DUT's terminals.
• At least two DUTs are used for validation.
• Tests for devices on a secondary feed, such as a 5 V sensor powered by a 12 V DUT, are adjusted by agreement.

The two long-term overvoltage tests in the preview are fixed-level holds. For alternator regulator failure, a 12 V system sees 18 V and a 24 V system 36 V, for 60 minutes, in a hot air oven 20 K below Tmax, with minimum functional status class C required. Jump start simulates a 24 V donor on a 12 V vehicle: 26 V for (60 ± 6) s, shaped per the clause's figure, at room temperature and, unless waived by agreement, at Tmin.

Where does load dump live: ISO 16750-2, ISO 7637-2, ISO 21780 or LV 124?

Four documents sit near load dump, and they are easy to mix up.

For magnitudes, TI's application note SLVAES2 cites the 2010 edition of ISO 16750-2: an unsuppressed load dump can peak at up to 101 V in 12 V systems and 202 V in 24 V systems, lasting 40 to 400 ms depending on the test level. Where the alternator has centralized suppression, TI gives 35 V as the suppressed peak for 12 V systems, and TI's LM74700-Q1 datasheet calls that case "ISO-16750-2 pulse B." Check those numbers against your edition before using them.

LV 124, per the same TI article, was drawn up by Audi, BMW, Daimler, Porsche and Volkswagen. Its tests overlap with ISO 16750-2 by name: E-01 long-term overvoltage, E-04 jump start, E-06 superimposed AC, E-07 slow decrease and increase, E-09 reset, E-10 short interruptions, E-11 cold crank and E-15 reverse polarity. TI describes E-06 ripple as high as 6 V peak to peak on 13.5 V DC, swept from 15 Hz to 30 kHz, and E-10 interruptions from 10 µs to a few milliseconds. Shared names do not mean shared parameters.

Which ISO 16750-2 profiles can a programmable power supply run?

In list mode, a programmable supply steps through voltages on its own clock, independent of your PC. On the Keysight N6700, list mode exists on N676xA modules, N678xA SMUs and modules with Option 054. Five limits from its programmer's reference decide what fits:

• Length. A list holds up to 512 steps and repeats 1 to 256 times, or indefinitely.
• Dwell. Each step lasts 0 to 262.144 s, with 1 µs resolution below 0.262144 s. A 60-minute overvoltage hold is several steps, or a fixed setpoint and a timer.
• Slew. VOLT:SLEW sets a true ramp, but its minimum scales with the voltage range: about 4.76 V/s on a 50 V range, so about 1.5 V/s even on a range that only just reaches 16 V. Clause 4.2's 1 V/s slope has to be a staircase. A 10 V ramp in 20 mV steps is 500 steps, nearly the whole list; 50 mV steps cut it to 200, still four times finer than the ±0.2 V tolerance.
• Protection. If a protection shutdown occurs during a list, the list keeps running with the output off, and the output resumes at the current step once the fault is cleared. A run with a protection event is not the profile you programmed.
• Measurement. On modules that measure both at once, the digitizer samples voltage and current together at intervals down to 10.24 µs, up to 256 K points.

Dwell resolution is not edge speed. A 100 µs step on the list timer still takes as long as the output stage needs to slew and settle, and a supply that sinks little current cannot pull a DUT's input capacitance down faster than that capacitance discharges. So supply range, both overvoltage holds, slow ramps, and dips of milliseconds or longer suit the supply. Load dump pulses, ripple to 200 kHz, micro interruptions, reversed polarity and open circuits need a generator, an amplifier or switches, which your script can still trigger and log.

How do you automate an ISO 16750-2 profile in Python?

Treat each profile as data, flatten it into the supply's step table, run it with the digitizer armed on the same trigger, and record what the DUT did. The code uses PyVISA and Keysight's N6700 commands; SCPI instrument automation with Python covers the basics.

Describe the profile as data

Keep each profile as holds and ramps in data, so the numbers copied from the standard live in one reviewable place and the instrument's limits are checked before anything reaches the bench.

"""Voltage-time profiles as data, flattened into a list-mode supply's step table."""
import math
from dataclasses import dataclass
 
MAX_STEPS = 512        # N6700: LIST:VOLT and LIST:DWEL take up to 512 steps
MAX_DWELL_S = 262.144  # N6700: longest dwell for one list step
 
 
@dataclass(frozen=True)
class Segment:
    start_v: float
    end_v: float
    seconds: float
 
 
def hold(volts: float, seconds: float) -> Segment:
    return Segment(volts, volts, seconds)
 
 
def ramp(start_v: float, end_v: float, volts_per_s: float) -> Segment:
    return Segment(start_v, end_v, abs(end_v - start_v) / volts_per_s)
 
 
def to_steps(segments: list[Segment], step_v: float = 0.05) -> tuple[list[float], list[float]]:
    """Return (volts, dwell) lists. Ramps become staircases; long holds are split."""
    volts: list[float] = []
    dwell: list[float] = []
    for seg in segments:
        if seg.start_v == seg.end_v:
            n = max(1, math.ceil(seg.seconds / MAX_DWELL_S))
            volts += [seg.end_v] * n
        else:
            n = max(1, round(abs(seg.end_v - seg.start_v) / step_v))
            volts += [seg.start_v + (seg.end_v - seg.start_v) * k / n for k in range(1, n + 1)]
        dwell += [seg.seconds / n] * n
    if len(volts) > MAX_STEPS:
        raise ValueError(f"profile needs {len(volts)} steps; the list holds {MAX_STEPS}")
    return volts, dwell

from iso16750.profile import hold, ramp, to_steps
 
# Code A limits and 1 V/s slopes. The segment order and hold times here only
# exercise the staircase; take the real ones from the figure in your copy.
segments = [hold(16.0, 30), ramp(16.0, 6.0, 1.0), hold(6.0, 60), ramp(6.0, 16.0, 1.0)]
volts, dwell = to_steps(segments)
print(len(volts), round(sum(dwell), 3))  # 402 110.0
 
to_steps(segments, step_v=0.02)  # ValueError: profile needs 1002 steps; the list holds 512

Run it on a list-mode supply

The run loads the list, arms the transient and acquisition systems on the bus trigger, waits until both are ready, and fires one *TRG that starts the profile and the digitizer together, as Keysight's own examples do.

"""Run a voltage list on one Keysight N6700 channel and digitize V and I alongside it."""
import math
import time
 
import numpy as np
 
CC = 2                             # STAT:OPER bit: output in constant current
WTG_MEAS, WTG_TRAN = 8, 16         # STAT:OPER:COND? bits: waiting for a trigger
MEAS_ACTIVE, TRAN_ACTIVE = 32, 64  # acquisition / transient system initiated
QUES_BITS = {1: "OV", 2: "OC", 4: "PF", 16: "OT", 128: "LIM+", 512: "INH", 1024: "UNR", 2048: "PROT"}
MAX_POINTS = 200_000               # under the 256 K-point limit with voltage and current on
TICK = 20.48e-6                    # intervals above 20.48 us round to this increment
 
 
def _csv(values) -> str:
    return ",".join(f"{v:.6g}" for v in values)
 
 
def _wait(psu, ch: str, done, timeout_s: float) -> None:
    deadline = time.monotonic() + timeout_s
    while not done(int(psu.query(f"STAT:OPER:COND? {ch}"))):
        if time.monotonic() > deadline:
            psu.write(f"ABOR:TRAN {ch}")  # output returns to its pre-list settings
            psu.write(f"ABOR:ACQ {ch}")
            raise TimeoutError(f"{ch} did not reach the expected state in {timeout_s:.0f} s")
        time.sleep(0.05)
 
 
def run_list(psu, volts, dwell, current_limit_a: float, ch: str = "(@1)") -> dict:
    duration = sum(dwell)
    interval = math.ceil(duration / MAX_POINTS / TICK) * TICK  # an exact multiple, never short
    points = math.ceil(duration / interval) + 1
 
    psu.write("*RST;*CLS")  # *RST also aborts the transient and acquisition systems
    psu.write("STAT:PRES")  # every PTR bit on, so event registers latch each condition
    for command in (
        f"CURR {current_limit_a},{ch}",
        f"VOLT {volts[0]},{ch}",
        f"VOLT:MODE LIST,{ch}",
        f"LIST:VOLT {_csv(volts)},{ch}",
        f"LIST:DWEL {_csv(dwell)},{ch}",
        f"LIST:STEP AUTO,{ch}",
        f"LIST:TERM:LAST ON,{ch}",
        f"SENS:FUNC:VOLT ON,{ch}",  # both on needs a module with
        f"SENS:FUNC:CURR ON,{ch}",  # simultaneous V and I measurement
        f"SENS:SWE:POIN {points},{ch}",
        f"SENS:SWE:TINT {interval:.8g},{ch}",
        f"TRIG:TRAN:SOUR BUS,{ch}",
        f"TRIG:ACQ:SOUR BUS,{ch}",
        "FORM REAL",       # IEEE single precision blocks
        "FORM:BORD NORM",  # big-endian
        f"OUTP ON,{ch}",
    ):
        psu.write(command)
    err = psu.query("SYST:ERR?")
    if not err.startswith(("+0", "0")):
        raise RuntimeError(f"setup rejected: {err}")
    psu.query("*OPC?")  # output settled at the first step
 
    psu.write(f"INIT:ACQ {ch}")
    psu.write(f"INIT:TRAN {ch}")
    armed = WTG_MEAS | WTG_TRAN
    _wait(psu, ch, lambda c: c & armed == armed, timeout_s=5)
    t0 = time.time()   # host clock at the trigger, for lining up other logs
    psu.write("*TRG")  # starts the list and the digitizer together
    _wait(psu, ch, lambda c: not c & (MEAS_ACTIVE | TRAN_ACTIVE), duration * 1.2 + 10)
 
    fetch = dict(datatype="f", is_big_endian=True, container=np.array)
    v = psu.query_binary_values(f"FETC:ARR:VOLT? {ch}", **fetch)
    i = psu.query_binary_values(f"FETC:ARR:CURR? {ch}", **fetch)
    tint = float(psu.query(f"SENS:SWE:TINT? {ch}"))  # the interval actually used
    ques = int(psu.query(f"STAT:QUES? {ch}"))         # latched since *CLS
    oper = int(psu.query(f"STAT:OPER? {ch}"))         # latched too; CC = current limit engaged
    events = [name for bit, name in QUES_BITS.items() if ques & bit]
    if oper & CC:
        events.append("CC")
    return {
        "t0": t0,
        "t": np.arange(len(v)) * tint,
        "volts": v,
        "amps": i,
        "events": events,
    }

Three details matter. LIST:TERM:LAST ON leaves the output at the last step instead of snapping back to the pre-list setting. The questionable and operation event registers latch what happened during the run, so a protection trip, or an inrush that put the output into constant current (CC), still shows up. And the digitized voltage is what the supply's terminals saw; clause 4.1 wants the voltage at the DUT's terminals, so sense at the DUT connector or log a meter there.

Watch the DUT while the profile runs

The supply's record shows what was applied, not whether the DUT kept its functional status class. If the ECU sends a periodic status frame on CAN, a silence longer than a few periods marks a reset or a brownout. With python-can, the watcher is a thread, as in BMS validation testing:

"""Record the DUT's periodic status frame on CAN while a profile runs."""
import threading
 
import can
 
 
class FrameWatch:
    def __init__(self, channel: str, frame_id: int):
        self.channel, self.frame_id = channel, frame_id
        self.stamps: list[float] = []
        self._stop = threading.Event()
        self._thread = threading.Thread(target=self._run, daemon=True)
 
    def _run(self) -> None:
        with can.Bus(channel=self.channel, interface="socketcan") as bus:
            while not self._stop.is_set():
                msg = bus.recv(timeout=0.1)  # None on timeout
                if msg is not None and msg.arbitration_id == self.frame_id:
                    self.stamps.append(msg.timestamp)  # seconds since the epoch
 
    def __enter__(self):
        self._thread.start()
        return self
 
    def __exit__(self, *exc) -> None:
        self._stop.set()
        self._thread.join()
 
    def gaps(self, period_s: float, start: float, end: float,
             factor: float = 3.0) -> list[tuple[float, float]]:
        """(start, length) of every silence in [start, end] longer than factor x period.
 
        The window edges count as boundaries, so a DUT that never recovers, or a
        bus that recorded nothing, shows up as a gap rather than a clean pass.
        """
        s = [start, *(t for t in self.stamps if start <= t <= end), end]
        return [(a, b - a) for a, b in zip(s, s[1:]) if b - a > factor * period_s]

import pyvisa
 
from iso16750.n6700 import run_list
from iso16750.profile import hold, ramp, to_steps
from iso16750.watch import FrameWatch
 
volts, dwell = to_steps([hold(16.0, 30), ramp(16.0, 6.0, 1.0), hold(6.0, 60), ramp(6.0, 16.0, 1.0)])
 
rm = pyvisa.ResourceManager()
psu = rm.open_resource(
    "TCPIP0::192.168.1.60::inst0::INSTR",
    read_termination="\n", write_termination="\n", timeout=30_000,
)
 
# 0x18F every 10 ms stands in for your ECU's own status frame.
with FrameWatch("can0", frame_id=0x18F) as watch:
    run = run_list(psu, volts, dwell, current_limit_a=5.0)
 
print(run["events"])                # ['CC'] if the current limit engaged
for start, length in watch.gaps(period_s=0.010, start=run["t0"], end=run["t0"] + sum(dwell)):
    print(f"DUT silent {length * 1e3:.0f} ms at t = {start - run['t0']:.2f} s")

python-can timestamps each frame in seconds since the epoch, in hardware where the interface supports it, so lining frames up against t0 is good to a few milliseconds at best. That suits ramps and long dips. For micro interruptions, put a scope on the DUT's supply and reset line, triggered by the same switch that makes the interruption.

Record what a reviewer will ask for

For each run, keep the edition and clause, supply code, operating mode, temperature, the DUT serial number, the step table loaded, the digitized voltage and current, the CAN log, the status events, each instrument's *IDN? string and calibration due date, the operator, and the functional status class required against the one observed. Hardware test traceability links those records to requirements, and the DVT test report template rolls them into a report. For rails downstream of the supply input, see the power rail validation plan; for the loads that 4.10 overload cases need, see electronic load automation.

How to run an ISO 16750-2 profile in Galois with Évariste

Évariste, the agent in the Galois platform, runs the same profile on the same N6700 and ECU without you writing or maintaining the code above. Open it from the app sidebar (Ctrl+Shift+E) beside the project; AI test automation for hardware benches explains how it builds sequences.

Instruments. Ask "List connected instruments" to confirm the supply and the ECU, through its dbc2galois profile, are on your edge. If the supply has no profile yet, upload Keysight's programmer's reference and Évariste generates one. Check that it covers the LIST, TRIG, SENS:SWE, FETC:ARR and STAT commands the code uses before it is deployed to the edge and bound to the supply.

Objective. State the profile with the code's placeholder numbers, then swap in the real segments from the figure in your copy:

Create a sequence for ISO 16750-2:2023 clause 4.2, supply code A, on N6700 channel 1. Hold 16 V for 30 s, ramp to 6 V at 1 V/s as a 50 mV staircase in list mode, hold 6 V for 60 s, ramp back to 16 V at 1 V/s. Current limit 5 A. Digitize voltage and current from the same bus trigger as the list. Fail if a protection event latches and flag constant-current operation. Read the ECU's status signal and reset counter before the list and after it ends.

The reset counter stands in for whatever your DBC offers, as frame 0x18F does in the code. A counter that moved across the list shows a reset the ECU recovered from, which one status read at the end would miss.

Draft, review and approval. Évariste returns a draft sequence that cannot run until an engineer approves it. Read it step by step against the code above and look for the current limit set before the output turns on, voltage and dwell lists of at most 512 steps (this profile needs 402) with no dwell over 262.144 s, ramps as staircases rather than VOLT:SLEW, LIST:TERM:LAST ON, one bus trigger for the list and the digitizer, and protection and CC read from the latched event registers rather than the condition registers. How to review an AI-generated test plan covers the rest. Edit in conversation or in the sequence builder; every change is a new version with history and a diff, an edit after approval needs a new approval, and an approved version can be production-locked. Commands you send to the supply directly through Évariste still wait for your confirmation when they are dangerous.

Run, results and report. Start the run; galois-edge executes it while Monitor shows voltage and current live. Every step records its measured value, limits, pass or fail, raw command and response, instrument, operator, DUT serial and timestamps. Ask Évariste which steps failed or passed close to a limit, whether the reset counter moved, or to compare the Tmin and Tmax runs. Then ask it to "Generate a test report from the last run" and add the edition, operating mode, temperature and observed functional status class in the report editor.

You no longer write or maintain the list loading, status polling, timeout and abort handling, binary fetch, CAN thread, logging or report script. What stays with you: the numbers from your licensed copy, reviewing and approving the draft, the wiring and chamber, sense leads at the DUT connector because clause 4.1 measures at the DUT's terminals, and deciding whether the counter, the digitized trace or a scope on the reset line proves functional status class A.

Where Galois fits

Galois is agent-driven test engineering for hardware teams: agents generate tests and instrument drivers, run them on real benches through the open-source galois-edge daemon, and turn the results into reports and a shared engineering record.

The Apache-2.0 galois-edge daemon discovers instruments on GPIB, USB, LAN, serial, Modbus and CAN. Its dbc2galois script converts a vendor DBC file into a profile, so the ECU's status signals become typed commands next to the supply's. Profiles can define multi-step sequences that the daemon runs under a per-instrument lock, and sweeps, the daemon's mode for safety-critical ramps, keep running if the client drops. Galois ships 573 instrument profiles across 135 manufacturers (instrument library), and Évariste generates new ones from an instrument's programming manual; declarative instrument drivers explains the format. The Évariste walkthrough above runs this guide's profile on that same stack.

A compliance-check branch that assembles standards findings and sign-off packages from run evidence is in build. Evidence of that kind supports a certification or a customer approval; it never grants one.

Agents can drive the same bench through MCP tools; LLM instrument safety covers the guardrails. See the product overview, or run the daemon on your own bench with the quickstart.