This is a proposal for a future mandatory interface to support the testing of Connected and Automated Vehicles (CAVs), to be installed in all production vehicles, hence "On-Board Validation" or OBV. This would allow independent validation of CAVs by third parties, and comparative tests between models from different manufacturers. Here we look well beyond current official work to a possible "new world" in CAV testing.

OEMs/ADSEs must perform a huge volume of diverse testing for automated vehicles, much of it in simulation. Currently this can only be audited by others for the purposes of certification, not re-run; and that will always be required. Only a very small number of real high-level track tests can be performed by third parties. But this is somewhat unsatisfactory in terms of public and regulator trust. By adding a standard test interface, we can open the door to much broader and deeper independent testing covering perception, behaviour, and vehicle control. Retesting after software updates for the whole vehicle life is facilitated.

On-board diagnostics (OBD) today provides a highly successful precedent for a physical and communications interface, accepted by OEMs to expose internal vehicle data to third parties, but which also has many manufacturer uses in development and maintenance. For OBV, Ethernet would be the likely physical layer, and while the protocol must be extensible, Open Simulation Interface (OSI) may provide the basis to communicate object and trajectory data. The OBD port might still be used.

To test perception, we command the vehicle to report what objects and infrastructure it can detect over the OBV interface, while real static and moving test track targets are placed around it. It does not matter what sensors or algorithms it uses; can the vehicle "see" what it is shown?

For path planning, we command the vehicle to remain stationary and ignore its own perception inputs. Instead the test tool streams in object data via the OBV interface, and requires the vehicle to emit its planned trajectory and signal outputs, which are then graded. In effect any vehicle taken off the street can then participate in independent real-time HIL scenario testing, where the test tool acts as a simulator.

Finally for vehicle control, we return to the track, and command the vehicle to follow trajectories of our choosing, consistent with its capabilities. Furthermore, we may request its Minimum Risk Manoeuvre on demand. The vehicle is instrumented so that its true movement can be graded.

The new OBV interface would place architectural constraints and software work on the OEMs, yet the confidentiality of their algorithms would be preserved. The interface would also be useful to OEMs however in development work, sensor maintenance and calibration, and their own testing. It would have sufficient bandwidth to replace one or two sensor streams with injected synthetic data for example. Data could be extracted both for mandatory logged events, and detailed manufacturer logs to understand failed third-party tests or in-use anomalies. Strict cybersecurity would be required to restrict access only to properly authorised test tools.