[Ovmsdev] OBD/UDS Poller receiver rework

Fri Aug 28 04:00:17 HKT 2020

Everyone,

I've just pushed the poller receiver changes I announced into the new
"poller-rework" branch:

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/0b306ad4f5e7a1eb63a471a11ec7f1a6d69d8647

OBD/UDS Poller Receiver Rework:

  - Fix race condition between CAN RX and PollerReceive
  - Separation of ISO-TP & OBD/UDS layer meta data analysis
  - Fix incomplete meta data validation
  - Allow single/multi frame responses on all service types
  - Validate multi frame response sequences
  - Fix single frame payload lengths
  - Fix type 0x22 first frame payload offset & overall length
  - Add negative response code handling → IncomingPollError()
  - Add response frame timing control → PollSetResponseSeparationTime()

This rework has been on my list for some time before, as the previous
solution had some general shortcomings, especially by it's hard coded
coupling of the expected response transport form with the request type,
which fails already on some type 0x01 requests.

The major bug in the receiver that now triggered the rework was in the
overall payload length calculation and the first frame payload passing
of the type 0x22 (VEHICLE_POLL_TYPE_OBDIIEXTENDED) multi frame response
handling. That up to now basically only turned up as a visible issue for
the Smart ED, as all other vehicles either don't get multi frame
responses on 0x22 queries or (like the Kia) generally discard the first
frame and don't use the overall length at all.

On the Smart ED, all handlers have been deliberately written assuming
the bug was a feature -- all payload addressing is shifted by one byte.
This needs to be rewritten now.

All other vehicles should not see any difference and should not need to
change any code. Except maybe in the UpMiiGo development, which isn't
yet part of the master.

Other bugs like the missing frame sequence validation and late response
detection may have been the causes for some spurious and hard to track
crashes and data errors. We should try to get this change tested short
term on "edge", so we can see if this actually improves stability as I hope.

As this is a major rework (mainly of the PollerReceive() method), audits
and tests are very welcome. I can only test on the Twizy, which doesn't
make much use of the poller yet.

You can see what the new poller does by raising the log level for
"vehicle" to debug. Example of some Twizy regular polling:

D (136323) vehicle: PollerSend(1): send [type=10, pid=C0], expecting
743/763-763
D (136343) vehicle: PollerReceive[763]: process OBD/UDS response 10(C0)
frm=0 len=0 off=0 rem=0
V (136343) v-twizy: OBD2: ignored reply [10 c0]
D (137323) vehicle: PollerSend(1): send [type=21, pid=81], expecting
743/763-763
D (137343) vehicle: PollerReceive[763]: process OBD/UDS response 21(81)
frm=0 len=4 off=0 rem=15
D (137373) vehicle: PollerReceive[763]: process OBD/UDS response 21(81)
frm=1 len=7 off=4 rem=8
D (137403) vehicle: PollerReceive[763]: process OBD/UDS response 21(81)
frm=2 len=7 off=11 rem=1
D (137423) vehicle: PollerReceive[763]: process OBD/UDS response 21(81)
frm=3 len=1 off=18 rem=0
D (137433) v-twizy: OBD2: got VIN='XXXXXXXXXXXXXXXXX'
D (138323) vehicle: PollerSend(1): send [type=21, pid=13], expecting
743/763-763
D (138343) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=0 len=4 off=0 rem=106
D (138373) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=1 len=7 off=4 rem=99
D (138403) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=2 len=7 off=11 rem=92
D (138423) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=3 len=7 off=18 rem=85
D (138453) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=4 len=7 off=25 rem=78
D (138483) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=5 len=7 off=32 rem=71
D (138513) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=6 len=7 off=39 rem=64
D (138543) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=7 len=7 off=46 rem=57
D (138563) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=8 len=7 off=53 rem=50
D (138593) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=9 len=7 off=60 rem=43
D (138623) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=10 len=7 off=67 rem=36
D (138653) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=11 len=7 off=74 rem=29
D (138683) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=12 len=7 off=81 rem=22
D (138703) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=13 len=7 off=88 rem=15
D (138733) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=14 len=7 off=95 rem=8
D (138763) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=15 len=7 off=102 rem=1
D (138793) vehicle: PollerReceive[763]: process OBD/UDS response 21(13)
frm=16 len=1 off=109 rem=0
W (141323) v-twizy: OBD2 Cluster DTC NEW #01: 4/21 rev0 G1 INT MEM Ef|  
@ 57871km 11kph SOC=60% BV=14V TC=0 IC=255
W (141333) v-twizy: OBD2 Cluster DTC NEW #02: 4/1 rev0 G1 MEM|   @
57892km -1kph SOC=86% BV=14V TC=0 IC=255
W (141343) v-twizy: OBD2 Cluster DTC NEW #03: 1/37 rev0 G1 INT MEM Ef|  
@ 57892km -1kph SOC=86% BV=14V TC=0 IC=255
W (141353) v-twizy: OBD2 Cluster DTC NEW #04: 3/59 rev0 G2 INT MEM|   @
57926km 34kph SOC=78% BV=14V TC=0 IC=255
W (141363) v-twizy: OBD2 Cluster DTC NEW #05: 4/40 rev0 G2 MEM Ef|   @
57926km 35kph SOC=78% BV=14V TC=0 IC=255
W (141373) v-twizy: OBD2 Cluster DTC NEW #06: 3/58 rev0 G2 INT MEM|   @
58711km 41kph SOC=46% BV=14V TC=0 IC=255

A manual multi frame poll:

I (147723) webcommand: HttpCommandStream[0x3f8540f4]: 3801804 bytes
free, executing: x o r bm 2104
D (148323) vehicle: PollerSend(1): send [type=21, pid=4], expecting
79b/7bb-7bb
D (148343) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=0 len=4 off=0 rem=70
D (148353) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=1 len=7 off=4 rem=63
D (148393) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=2 len=7 off=11 rem=56
D (148433) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=3 len=7 off=18 rem=49
D (148473) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=4 len=7 off=25 rem=42
D (148513) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=5 len=7 off=32 rem=35
D (148553) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=6 len=7 off=39 rem=28
D (148593) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=7 len=7 off=46 rem=21
D (148633) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=8 len=7 off=53 rem=14
D (148673) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=9 len=7 off=60 rem=7
D (148713) vehicle: PollerReceive[7BB]: process OBD/UDS response 21(4)
frm=10 len=7 off=67 rem=0
OVMS# x o r bm 2104
Response:
08 cc 3c 08 d4 3c 08 cb 3c 08 d6 3c 08 ce 3c 08 | ..<..<..<..<..<.
d1 3c 08 d2 3c ff ff ff ff ff ff ff ff ff ff ff | .<..<...........
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ................
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff | ................
ff ff ff ff ff ff ff ff 3c 3c                   | ........<<     

An example of the new error response handling:

I (165023) webcommand: HttpCommandStream[0x3f8479f4]: 3791052 bytes
free, executing: x o r bm 221405
D (165323) vehicle: PollerSend(1): send [type=22, pid=1405], expecting
79b/7bb-7bb
D (165343) vehicle: PollerReceive[7BB]: process OBD/UDS error 22(1405)
code=11
OVMS# x o r bm 221405
ERROR: request failed with response error code 11

Code 11 = "serviceNotSupported" (see ISO 14229 Annex A.1 for more codes)

Feedback is welcome.

Regards,
Michael

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200827/fc6c7326/attachment.html>