Frage UDS TesterPresent

Nimm einfach mal an, ich sei gerade vom Fruehstueck aufgestanden und habe jetzt Deine Frage gelesen. Jetzt versuche mal, Dir vorzustellen, ob ich wissen koennte worum es geht.

Vermutlich sowas:

• https://de.wikipedia.org/wiki/Unified_Diagnostic_Services

Also ab damit ins Automotive-Forum.

Lothar M. schrieb:

Vermutlich sowas:

• https://de.wikipedia.org/wiki/Unified_Diagnostic_Services

Ja da stehen aber nur die einzelnen services beschrieben. Aber meine Frage kann ich damit leider nicht beantworten

Chandler B. schrieb:

Kann es vorkommen, dass vom Tester während dieser conductive-frames schickt (z.B. bei Transfer-Data), zwischendrinn ein Tester-Present als request schickt?

Meinst du "consecutive frames"?

Ich würde mal vermuten: nein, kann nicht vorkommen. Die laufende Übertragung muss zuerst beendet werden.

Hast du mal in die Spec des ISO-TP geschaut? Die Transmit-API wird in so einem Fall vermutlich entweder E_BUSY melden oder den neuen Request in eine Queue einreihen.

Wendels B. schrieb:

Nimm einfach mal an, ich sei gerade vom Fruehstueck aufgestanden und habe jetzt Deine Frage gelesen. Jetzt versuche mal, Dir vorzustellen, ob ich wissen koennte worum es geht.

Wenn Du Dich mit UDS auskennen würdest, wüsstest Du worum es geht. Und wer das Protokoll nicht kennt, der weiß auf so eine Spezialfrage ohnehin keine Antwort.

Tester Present ist nur ein Trigger um das Steuergerät wachzuhalten. Da kommt keine Antwort ausser dem normalen CAN Acknowledge.

Im Steuergerät gehen Tester Present und der Diagnosejob an verschiedene Tasks, die unabhängig voneinander agieren. Daher dürfte die Reihenfolge egal sein. Der Diagnosejob bekommt vom Tester Present genauso wenig mit wie von all den anderen Botschaften auf dem Bus.

Wenn ich das implementieren müsste, würde ich trotzdem erst den Job abschließen und dann den nächsten TP senden. Ist ja deine Entscheidung. Ob der TP ein paar frames früher oder später kommt ist völlig egal.

Le X. schrieb:

Ich würde mal vermuten: nein, kann nicht vorkommen. Die laufende Übertragung muss zuerst beendet werden.

Hast du mal in die Spec des ISO-TP geschaut?

Ja, dort habe ich aber nichts dazu gefunden :/

Die Überlegung kam auf in folgendem Szenario: Der Tester sendet einen FirstFrame zur ECU. Dieser Antwortet mit einem FlowControl Frame, wo der wert STMin definiert ist. Dies ist ja aber nur die minimale zeit. Angenommen der Tester muss nach dem FirstFrame noch weitere 10 ConsecutiveFrames schicken und nach dem 5. Frame macht der Tester eine Pause (warum auch immer). Wenn dann P2star in meiner ECU ablaufen würde, würde ich ja die Session wieder verlassen.

Ich hoffe nicht, dass so etwas vorkommt, aber ich weiß halt auch nicht, ob ich das abfangen muss.

Soul E. schrieb:

Tester Present ist nur ein Trigger um das Steuergerät wachzuhalten. Da kommt keine Antwort ausser dem normalen CAN Acknowledge.

vielleicht solltest Du nochmal die UDS Spec genau lesen, Hinweis suppress positive response. Wird normal gesetzt, muss aber nicht.

In der ECU muss das TP auch im Diag verarbeitet werden um ggfs. Rückwechsel in die Default-Session zu unterbinden. Damit das ganze einfacher zu handhaben ist wird TP auf der funktionalen ID geschickt. So ganz unabhängig ist das nicht, gerade wenn man sich mal die Grenzfälle anschaut.

Ein TesterPresent kann jederzeit kommen, auch während eines laufenden segmentierten Transfers. In der Praxis sieht das so aus, dass die Steuergerätesoftware das TesterPresent (3E 80, also unterdrückte positive Response) schon auf unterster Ebene detektiert und die Timer aufzieht, ohne übers ISOTP/UDS laufen zu müssen, weil das ja gerade mit einem segmentierten Transfer beschäftigt sein könnte.