OBD Request Priority?

Some OBD-II apps allow users to assign a priority to each request for PID/sensor data. From my limited understanding of the CAN protocol, priority is determined from the message identifier alone. But car manufacturers add higher-layer protocols over CAN.

Does anyone know whether Toyota adds something that assigns priority to CAN nodes (so presumably the OBD node would be assigned a low priority, then OBD apps could rank requests within this low priority)?

Otherwise, is there a safety risk through overloading the vehicle bus with multiple (high-priority, OBD) data requests if logging data while driving?

 

I have explored this a little more (with some input from OBD app developers).

The priority set for PIDs in OBD apps is a ranking of the frequency of requests for data from those sensors, or in some apps a difference in minimum interval (in clock cycles) between requests. In many cases, the app can be set to restart requests as soon as the last response is received (eg log on PID frame).

This differs from arbitration priority (based on the message ID) in CAN.

The two are indirectly related insofar as CAN system designers probably assign lower (ID) priority to PIDs (sensors) that refresh less frequently into the bus; and OBD app developers probably aim to assign lower request frequencies to such PIDs.

A 500 kbaud 11 bit CAN bus should be able to deliver 125-bit frames (PID results) at the rate of 4,000 frames per second. Designers aim to keep a bus below 30% load, which would still be >1,000 PIDs/sec. But a modern car may have in the order of 1,000 sensors reporting PID readings over the CAN bus. Some sensors (like those for ABS braking) must update many times per second; others (like temperatures) much more slowly.

Hybrid cars probably have more sensors, and thus a greater load on the data bus, relative to ICE-only cars.

OBD apps certainly vary in overall data refresh rates. All seem to be limited by factors other than the frame rate handled by a modern CAN bus. For example, addition of more PID requests always seems to slow down the rate of refresh for each PID. I am not sure if these factors are incidental to car safety (eg limits of the OBD dongle or host computer data processing) or explicitly introduced to ensure safety.

Using OBDLink (≈OBD Fusion), I have logged dozens of PIDs without apparently influencing car function while driving. This app seems relatively slow (10-20 OEM PIDs/sec in my hands), but maybe that means it is relatively safe?

I am still not sure if Toyota uses a mechanism (like a protocol for node priority or a gateway module that controls OBD data flow) to control data requests from the OBD port. If not, one can imagines a scenario under which the CAN bus might be overloaded.

Probably the best advice for now is to be careful unless you know exactly how far you are pushing CAN data load towards an unsafe level. Can anyone contribute more insight?

 

Thanks ChapmanF, not sure if I would know how to interpret topologies in a manual but I will look.

OBDLink will read SAE PIDs and one OEM "network" at the same time. In the 2019 Toyota set (for AXAH54 Rav4, but probably the same for all hybrids that year) "Network A" has most sensors, including those in ECUs for ABS, Engine and Hybrid control (see images below, which have 1 ECU overlap). "Network C" seems a bit less critical (though things like parking brake and blind spot monitors are safety-related). Until your post I have been thinking that the (central) CAN bus carries everything, even if the data path is sensor to ECU to bus. But even if each "Network" is a separate bus (probably true), and not all sensor data flows between them (though some data obviously does), the "Network A" bus is obviously important for vehicle control, and it carries a lot of sensors/data, and it is open to OBD requests. So the questions of (a) whether the extra load from OBD logging might pose a risk and (b) whether Toyota does something to limit this still seem to arise (for me).

A related observation is that different 11/500 bus cars from different manufacturers seem to allow different OBD data refresh rates, but it is hard to be certain from the evidence which typically involves at least one extra variable (like the OBD app host device). If this is right, it would make sense from differences between manufacturers in strategies to limit OBD interference with their car data bus(ses).

I don't think much can be done about bus bandwidth - is that not fixed in an 11 bit / 500 CAN bus (the current legislated standard)?

 

Thanks again ChapmanF. On first reading I did not fully absorb your important observation that most sensors (and actuators on the output side) are wired directly to the relevant ECU, and not to a CAN bus.

This means that data traffic on the CAN bus(es) comprises requests for, and responses with, data that is needed by other ECUs. While considerable, this is only a small fraction of the total data generated by all of the vehicle’s sensors. The risk of overwhelming an 11/500 CAN bus with requests from the OBD is correspondingly reduced.

Perhaps there is no need (for safety) to assign node priorities or limit the OBD node.

But OBD data still seems slower than expected (from an 11/500 CAN bus), and it would be interesting to understand if any of this is down to the car.

 

Though I guess too many logged OBD requests could undesirably increase the load on an already-busy ECU. For example, the Hybrid Control ECU alone lists more than 300 PIDs (probably fewer per model when connected, and many obviously relayed from some other ECU, but you get the idea).

 

Toyota does use higher-level protocols and a gateway ECU between OBD port (DLC3) and car CAN bus, but I can not find any disclosure of effects on OBD data rates, even behind the information paywall imposed on Toyota car owners.
The example below is from a RAV4HV (AVA44). Other ECUs on CAN and LIN buses connect at places marked twiddle.