OBD Request Priority?

Discussion in 'Prius OBDII Third-Party Apps' started by RGeB, Jan 20, 2023.

  1. RGeB

    RGeB Member

    Joined:
    Apr 18, 2021
    108
    16
    0
    Location:
    Australia
    Vehicle:
    Other Hybrid
    Model:
    N/A
    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?
     
  2. RGeB

    RGeB Member

    Joined:
    Apr 18, 2021
    108
    16
    0
    Location:
    Australia
    Vehicle:
    Other Hybrid
    Model:
    N/A
    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?
     
  3. ChapmanF

    ChapmanF Senior Member

    Joined:
    Mar 30, 2008
    19,394
    12,944
    0
    Location:
    Indiana, USA
    Vehicle:
    2010 Prius
    Model:
    IV
    I might not know much about Gen 4 or 5, but at least through Gen 3 I have not seen Toyota hanging lots of sensors independently on the CAN bus where ECUs would have to send them queries.

    It seems much more common (at least through Gen 3) for the sensors to be simpler devices that are just wired back to an ECU, and the ECU directly reads them. If you sent a PID query for that sensor reading, you're getting it from the ECU.

    Two exceptions in Gen 3 are the yaw and acceleration sensor, and the steering angle sensor, pretty much simple sensors that have their own CAN addresses.

    I also don't know if the later generations segregate the CAN buses the way Gen 3 does. Gen 3 has at least two CAN buses, up to four depending on packages. CAN No. 1 bus has most of the bread-and-butter ECUs (and the yaw/acceleration and steering angle sensors); CAN No. 2 bus is for gossip between the parking assist, driving support, and pre-collision (seat belt control) ECUs; the Power Management CAN bus lets the power management control ECU converse with the HVAC and skid ECUs and ECM (the latter two also sit on the No. 1 bus), and the Parking Assist CAN bus connects the driving support ECU with the lane recognition camera and the millimeter-wave radar.

    So those last two things are sophisticated 'sensors' that probably produce a lot of data over that bus, but it's a separate bus not being shared by other traffic.

    The CAN No. 1 bus is the only one that appears at the DLC3 connector. So when a scan tool is getting information from something on one of the other buses, another issue is the burden that places on one of the ECUs that sit on both buses to relay queries and responses across. (Talking to the radar or lane camera would require two relay hops.)

    For all I know, Gen 4 or Gen 5 could have simplified that and just hung everything on one giant high-bandwidth CAN bus, or they might have continued the practice of separate buses where traffic might be lighter or heavier. Looking up those topologies in the manual might be important.
     
    RGeB likes this.
  4. RGeB

    RGeB Member

    Joined:
    Apr 18, 2021
    108
    16
    0
    Location:
    Australia
    Vehicle:
    Other Hybrid
    Model:
    N/A
    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)?

    Screenshot_20230122-155404[1].png Screenshot_20230122-155429[1].png Screenshot_20230122-155439[1].png
     
  5. RGeB

    RGeB Member

    Joined:
    Apr 18, 2021
    108
    16
    0
    Location:
    Australia
    Vehicle:
    Other Hybrid
    Model:
    N/A
    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.
     
  6. RGeB

    RGeB Member

    Joined:
    Apr 18, 2021
    108
    16
    0
    Location:
    Australia
    Vehicle:
    Other Hybrid
    Model:
    N/A
    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).

    Screenshot_20230124-082133.png
     
  7. RGeB

    RGeB Member

    Joined:
    Apr 18, 2021
    108
    16
    0
    Location:
    Australia
    Vehicle:
    Other Hybrid
    Model:
    N/A
    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.

    Gateway.jpg