Frage UDS TesterPresent

[Chandler B. (chandler)]

Hallo,
ich habe eine frage bzgl. UDS und hoffe, dass hier jemand eine Antwort 
darauf hat.

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

Oder muss ein gestarteter Request erst bis zum ende gesendet werden?

In der ISO konnte ich so einen fall nirgends finden.

[Wendels B. (wendelsberg)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Vermutlich sowas:
- https://de.wikipedia.org/wiki/Unified_Diagnostic_Services

Also ab damit ins Automotive-Forum.

[Chandler B. (chandler)]

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

[Le X. (lex_91)]

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.

[Soul E. (soul_eye)]

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.

[Chandler B. (chandler)]

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.

[Chris R. (rcc)]

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.