Automatische ISOTP-Fragmentierung erkennen

Guten Tag,

ich arbeite an UDS-Multi-Adapter-Software. Die größte Herausforderung in diesem Bereich ist immer das Senden von ISOTP-Multi-Frames.

Der (alte) ELM hat weder Segmentierung noch Codierung. Man muss also selbst segmentieren und je nach Format die ISOTP-Frames mit oder ohne Erwartung einer Antwort senden.

Der STN hat an/aus-schaltbare Segmentierung, aber keine Codierung, d.h. man kann ihm 80 Bytes senden und dann teilt er die in 10 CAN-Frames auf, macht aber keine ISOTP-Encodierung in FF und CF.

Der UniCarScan macht – was mich sehr überrascht und erfreut hat – nicht nur Segmentierung, sondern offenbar auch ISOTP-Codierung. Jetzt stellt sich mir die Frage, als jemandem, der möglichst viele Adapter unterstützt: Kann ich diese Funktionalität erkennen anhand irgendeines Parameters oder gar ein-/ausschalten?

Ich könnte natürlich zur Not auf den Namen des Adapters (auf anderer Softwareebene) prüfen – es wäre aber schöner, wenn ich es auf AT-Ebene herausfinden könnte. Geht das? Gibt es eine komplette Dokumentation etwaiger Adapter-Sonderfälle?

Hallo,

die Segmentierung ist die Extra Funktion von dem UniCarScan und wird von ELM Chips grundsätzlich nicht unterstützt. Ob es UniCarScan ist, kann mit AT#1 (Hersteller) und AT@1 (Firmware Version) geprüft werden.

Danke, AT#1 war mir neu.

Ich habe die automatische Fragmentierend mal ausprobiert, aber ich bekomme Fehler mit unvollständigen CAN-Frames, wenn das Payload nicht direkt "aufgeht".

Beispiel: Ich übermittele an den Adapter 2EF15A0004140606FFFFFFFF.

Ich erwarte, dass gesendet wird:

10 0C 2E F1 5A 00 04 14
21 06 06 FF FF FF FF 00

Der UniCarScan sendet allerdings

10 0C 2E F1 5A 00 04 14
21 06 06 FF FF FF FF

Der letzte Frame wird nicht "aufgefüllt" auf 8 Bytes und ist daher unvollständig.
Woran liegt dieses Verhalten?

Ist ja alles richtig. Es wird das gesendet, was geschickt wurde. 00 ist auch ein Byte, mit dem Wert 0. Warum soll es gesendet werden? Bei CAN Bus gibt es keine Platzhalter. Die Länge der segmentierten Nachricht bestimmt in diesem Fall 0C.

Bin mir nicht sicher, ob ich Sie richtig verstanden habe. Soweit ich sehe, ist das UniCarScan-Verhalten bei langen Frames hier nicht korrekt. Ein OBD2-Adapter sollte _nie_ unvollständige CAN-Frames schicken, sondern _immer_ auffüllen. Die Steuergeräte, die ich kenne, verwerfen unvollständige CAN-Frames.

Wenn ich nur solche langen Datenpakete schicken kann, die auf Vielfache von 6+n*7-Payload-Bytes "aufgehen", dann kann ich manche UDS-Kommandos (0x22, 0x36) nicht korrekt übertragen, denn der UniCarScan kann ja nicht "wissen", ob ich Extrabytes schicke, damit das Paket "aufgeht" oder ob die Extrabytes tatsächlich zum UDS-Message-Payload gehören.

Bei CAN Bus gibt es keine Fill-Bytes. Wenn 132 Bytes zu versenden sind, dann werden nur diese 132 Bytes versendet, ohne dass man etwas auffüllen muss. Und wenn für den letzen Frame der Nachricht nur 3 Bytes übrig bleiben, dann wird DLC (Datenlänge) entsprechend nicht auf 8 sondern kleiner gesetzt. Im Anhang ist ein Beispiel.