Diskussion:Unified Diagnostic Services

Letzter Kommentar: vor 3 Jahren von MAbW in Abschnitt OBD-Dienste

Dienste Bearbeiten

Unter "Dienste" wird behauptet, dass ein Service erst dann abgeschlossen wird, wenn vom Steuergerät eine positive, oder negative Response gesendet wird. Das stimmt bei UDS nicht. Wird im Request in der Subfunction das "suppressPositiveResponseMessage" Bit gesetzt soll das Steuergerät positive Antworten unterdrücken. Dies ist ein entscheidender Vorteil von UDS gegenüber KWP. (nicht signierter Beitrag von 213.30.210.169 (Diskussion) 13:48, 9. Dez. 2010 (CET)) Beantworten

Sorry, aber korrekterweise handelt es sich um das SPRMIB, das SuppressPositiveMessageIndicationBit (nicht signierter Beitrag von 77.4.129.227 (Diskussion) 19:45, 17. Jul 2012 (CEST))

Hex Values Bearbeiten

Hier werden auch die einzelnen Dienste aufgezeigt wie DTC lesen usw. Wäre es denkbar hier auch kurz auf die HexWerte die hierfür gesendet werden ein zu gehen? Also DTC lesen, es wird der Hex wert 0xXX auf den bus gelegt, als Antwort wäre X Y oder Z? Wäre voll toll. Es ist sehr schwierig so detailierte info im internet zu finden... link wäre auch schon toll. Grüße, euer Schorsch (nicht signierter Beitrag von 212.77.163.106 (Diskussion) 12:21, 7. Jul 2011 (CEST))

Gerade solche Details sind der Grund, warum viele Informatik Artikel für Laien nicht lesbar sind. Informationen wie, „der Dienst xy wird durch den folgenden Hexwert Symbolisiert“, trägt nicht dazu bei das Thema UDS besser zu verstehen. Wenn man es genau nimmt, dann geht dieser Artikel schon jetzt viel zu sehr ins Detail, wobei ich zugeben muss, dass ich selber auch etwas Schuld daran bin.
Ich wäre ja schon Glücklich, wenn ich meinem Projektleiter (der keine Ahnung von Informatik hat) diesen Artikel in die Hand drücken könnte und er danach eine Grobe Vorstellung davon hat was UDS ist und was dieses Protokoll alles leisten kann. Er muss aber nicht wissen, dass ein Reset durch eine 11 Symbolisiert wird, wozu auch. --Stefan2 (Diskussion) 19:43, 29. Jul. 2012 (CEST)Beantworten
Moin. Wo steht denn, dass Wikipedia-Artikel nur für Laien nützlich sein sollen? Konkrete Werte sind IMHO Fakten, die zu einer vollständigen Darstellung eines in Bits und Bytes implementierten Protokolls dazugehören, so wie z. B. in einen Artikel über ein spezielles Thema der Chemie oder Mathematik chemische bzw. mathematische Formeln gehören. Es sollte doch wohl möglich sein, das auf eine Weise im Artikel darzustellen, die Neulinge nicht stört, z. B. in einer separaten Tabelle? Natürlich vorausgesetzt, unsere üblichen Anforderungen, z. B. WP:Q, sind erfüllbar. Dass die Werte in den Überschriften stören, sehe ich ja ein. Gruß --dealerofsalvation 06:59, 30. Jul. 2012 (CEST)Beantworten
Ich bin auch für Details. Wollte gerade nachschauen, ob der NRC (Negative Response Code) 0x24 standardmässig für "RequestSequenceError" steht, oder ob sich mein lieblings OEM das selbst ausgedacht hat. Info nicht gefunden. Aber falls sie hier gewesen wäre, hätte mir ein "es gibt einen NRC 'RequestSequenceError'" ohne die Zuordnung zu einem Hex-Wert auch nicht geholfen.-- Qarkino (Diskussion) (10:53, 23. Jan. 2013 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)Beantworten
Dann probier du es gerne mal. Ich werde es gerne verbessern, wenn es syntaktisch oder formal nicht optimal wird, nur fachlich kenne ich mich nicht aus. Gruß --dealerofsalvation 07:30, 24. Jan. 2013 (CET)Beantworten
Dafür gibt es genügend Mitleser die sich fachlich gut auskennen :-) 84.152.203.114 23:01, 13. Feb. 2013 (CET)Beantworten
SIDs sind jetzt drin. --Igge (Disk.) 10:55, 26. Jun. 2014 (CEST)Beantworten
Und wieder mal ein technischer Artikel, der durch überflüssige technische Deteils für Laien unbrauchbar gemacht wird. Ich glaube Ihr habt das Wikipedia Prinzip nicht wirklich verstanden. Die SIDs helfen weder einem Fachmann, da sie nur ein kleiner Teil der UDS-Botschaft sind, noch einem Layen, da sie zum verstehen von UDS schlicht und ergreifen überflüssig sind und von wichtigeren Informationen ablenken. Außerdem wäre es schön wenn man aus dieser riesigen Tabelle Fließtext machen könnte. 23:51, 25. Jul. 2014 (CEST) (ohne Benutzername signierter Beitrag von 217.225.246.2 (Diskussion))
Aber ohne die SIDs war der Artikel auch meiner Meinung nach auch nutzlos. Ich werde eventuell die Spalte der Response-Id entfernen durch die Regel Response-Id = Request-Id + 0x40 (nicht signierter Beitrag von 84.152.166.4 (Diskussion) 22:30, 8. Okt. 2014 (CEST))Beantworten

Referenzen zu anderen Standards Bearbeiten

  • Ich habe eben den Bezug von der ISO 15765 zu GMLAN bzw. General Motors gelöscht, weil das definitiv falsch ist. Wenn überhaupt könnte hier ein Verweis auf die GMW3110 stehen, aber ich bin mir nicht sicher, inwieweit das eingeflossen ist. Dazu Frage ich aber mal einen Ex-Kollegen.
  • Bei dem Verweis auf KWP2000 bin ich auch nicht sicher. Soweit ich das weiß, ist das schon die Basis für die ISO 15765 (DoCAN) und nicht für UDS.

--Torsten Knodt (Diskussion) 16:56, 29. Okt. 2013 (CET)Beantworten

"Unified" steht für die Unification von KWP2000 und GMW3110. Man hat die besten Seiten der beiden Protokolle zusammengeführt. UDS beerbt also teilweise KWP (session control) als auch GMW3110 (viele der IDs z.B. 3E80 für TesterPresent). 2001:A60:10D7:EC01:216:D4FF:FEDB:C380 19:06, 27. Feb. 2014 (CET)Beantworten

OBD-Dienste Bearbeiten

Warum wurden in der Auflistung der Dienste die OBD-Dienste (0x00..0x0F) weggelassen? --62.53.205.244 09:08, 5. Sep. 2014 (CEST)Beantworten

Ich vermute weil sie in der zu Grunde liegenden ISO-14229 auch nicht erwähnt werden (nur der Platz wird freigehalten) und weil teilweise bei den OEMs vollkommen verschiedene Abteilungen für OBD und UDS zuständig sind...(eigene Erfahrung bei zwei OEMs) (nicht signierter Beitrag von 84.152.166.4 (Diskussion) 22:30, 8. Okt. 2014 (CEST))Beantworten


Welche sollen das sein? Es gibt 0x00-0x0A nicht bei WWH-OBD. Das ist alles über 0x14, 0x19, 0x22 und 0x31 abgedeckt.--MAbW (Diskussion) 17:09, 9. Jul. 2020 (CEST)Beantworten

Max. Botschaftslänge Bearbeiten

Die Aussage "Dabei darf insgesamt eine Botschaftslänge von 4095 Byte nicht überschritten werden" im Artikel ist m.E. falsch. Diese Beschränkung bezieht sich nur auf UDS on CAN und liegt darin begründet, dass das CAN Transportprotokoll (ISOTP) eben nur 4095 Byte Payload übertragen kann. Auf Ebene UDS (OSI Layer 7) gibt es diese Einschränkung nicht. Die ISO-14229 redet von einem Length-Field von vollen 32 Bit. D.h. Längenbeschränkung UDS allgemein: 4 294 967 295 Eine Implementierung von UDS auf einem bestimmten Netzwerk kann dies einschränken, so wie das UDS on CAN macht.

Bitte in Zukunft Beiträge signieren! Deine Anmerkung ist aber soweit ich das beurteilen kann korrekt. Ist in der ISO 15765-2 auch so nachlesbar. Du kannst die Informationen gerne ergänzen, wenn es geht allgemeinverständlich (ist zugegebenermaßen schwierig bei diesem Thema) --Medic-M (Diskussion) 12:39, 29. Jan. 2015 (CET)Beantworten