Differences

This shows you the differences between two versions of the page.

--- de:doc:rfc_rtd-real-time-data-protocol-for-the-oobd-firmware [2014/09/20 18:09] – created wsauer
+++ de:doc:rfc_rtd-real-time-data-protocol-for-the-oobd-firmware [2014/09/21 11:45] (current) – wsauer
@@ Line 23: / Line 23: @@
-==== Concept ====
+==== Konzept ====
-To surround several constrains like bus speed, real time capabilities and memory size when recording real time data in OOBD, the following concept will be followed
+Um mehrere Einschränkungen, wie Bus-Geschwindigkeit, Echtzeitfähigkeit und die Speichergröße wenn Echtzeitdaten in OOBD aufgenommen werden einzuschliessen, wird das folgende Konzept verfolgt
-Um mehrere Einschränkungen, wie Bus-Geschwindigkeit, Echtzeitfähigkeit und die Speichergröße einzuschliessen wenn Echtzeitdaten in OOBD aufgenommen werden, wird das folgende Konzept verfolgt
     -Um die Verwendung von geistigem Eigentum zu vermeiden und die Datenfelder, die aufgezeichnet werden, nicht in der Firmware einprogrammieren zu müssen, werden sie stattdessen von der Anwendung beim Start konfiguriert
-     - Um unvorhersehbare Bus-Geschwindigkeit Engpässe zu vermeiden, werden die Daten nur in der Firmware gesammelt und nur auf Anfrage übergeben.
+    -Um unvorhersehbare Bus-Geschwindigkeit Engpässe zu vermeiden, werden die Daten nur in der Firmware gesammelt und nur auf Anfrage übergeben.
+    -Um die vorhandenen Code auf Anwendungsseite wieder zu verwenden, wird die Konfiguration und die Datenanforderung als Pseudo-UDS-Services implementiert: Dienst 27 (Daten schreiben) zum Konfigurieren, Service 22 (Daten lesen) zum Lesen
-Um die vorhandenen Code auf Anwendungsseite wieder zu verwenden, wird die Konfiguration und die Datenanforderung als Pseudo-UDS-Services implementiert: Dienst 27 (Daten schreiben) zum Konfigurieren, Service 22 (Daten lesen) zum Lesen
-==== Initialization ====
+==== Initialisierung ====
-Select the CAN RTD protocol
+Wähle das CAN RTD Protokoll
@@ Line 46: / Line 43: @@
-Open the CAN filters
+Öffnen der CAN Filter
@@ Line 55: / Line 52: @@
-This activates the CAN Real Time Protocol, clears the internal PID list and sets the CAN bus into "invisible listen" mode
+Dieses aktiviert das CAN
+^R^|eal^T^|ime Data ^P^|rotokoll|,^|löscht die interne PID Liste und setzt den CAN Bus in den "unsichtbar empfangen" Modus|^
-==== Configuration ====
+==== Konfiguration ====
-=== Commands ===
+=== Kommandos ===
-The data to listen to is defined by the application to the firmware with an 27- command:
+Die Daten, die empfangen werden sollen, werden von der Applikation mittels des 27- Kommando von der Firmware angefordert:
 <code>
-CanID Type [Length [cPos [cStart]]]
+CanID Typ [Länge [cPos [cStart]]]
 </code>
-Values not given use 0 as default value
+nicht angegebene Werte werden mit 0 as Default Wert vorbesetzt
-where the data byte meanings are as follows:
+in Diesem bedeuten die Datenbytes folgendes:
-^  Block  ^Length in Bytes ^  Meaning  ^  Comment  |
+^  Block  ^Länge in Bytes ^  Bedeutung  ^  Kommentar  |
-|  CanID  |  4  |CAN- ID to listen to (MSB ..LSB) |  |
+|  CanID  |  4  |CAN- ID die empfangen werden soll (MSB ..LSB) |  |
-|  Type  |  1  |Multi frame message type |0: Single Frame  \\ 1: Custom  \\ 2: ISO-TP |
+|  Typ  |  1  |Mehrfachrahmen Nachrichten Typ |0: Einzelrahmen  \\ 1: Kundenspezifisch  \\ 2: ISO-TP |
-|  Length  |  2  |total length of data telegram |in case of ISO-TP, data length is dynamically taken out of the First Frame header  \\ if not given, assumed as 8 (=single frame length) |
+|  Länge  |  2  |Gesamtlänge des Datentelegramms |in Fall eines ISO-TP, wird die Datenlänge dynamisch aus dem Nachrichtenkopf des ersten Rahmens ermittelt  \\ falls nicht angegeben, wird es als 8 angenommen (=Länge eines Einzelrahmens) |
-|  cPos  |  1  |Position of Sequence counter |-preliminary- If telegram type is custom, than this position (0-7) is used to identify the sequence counter inside the CAN frame. |
+|  cPos  |  1  |Position des Sequenzenzählers |-Vorbereitung- Wenn der Telegrammtyp kundenspezifisch ist, dann wird diese Position (0-7) benutzt, um den Seqenzenzähler innerhalb des CAN- Rahmens zu identifizieren. |
-|  cStar  |  1  |start value of Sequence counter |-preliminary- If telegram type is custom, than this value is used to identify the first frame by its sequence counter inside the CAN frame. |
+|  cStart  |  1  |Startwert des Sequenzzählers |-Vorbereitung- Wenn der Telegrammtyp kundenspezifisch ist, dann wird dieser Wert dazu benutzt, den ersten Rahmen durch den Sequenzzähler innerhalb des CAN- Rahmens zu identifizieren. |
-=== Errors ===
+=== Fehler ===
-^  Error Code  ^Meaning |
+^  Fehlerkode  ^Bedeutung |
-|  1  |Command too long:  there are more bytes gives as specified by the command format |
+|  1  |Kommando zu lang:  Es sind mehr Bytes gegeben, als durch das Kommando spezifiziert wurden |
-|  2  |out of Memory: Not enough memory to store the requested data buffer |
+|  2  |Kein Speicher mehr übrig: Es ist nicht genügend Speicher vorhanden, um den angeforderten Datensatz abzulegen |
-|  3  |CAN ID already exist: The requested CAN ID is already requested before |
+|  3  |CAN ID existiert bereits: Die angeforderte CAN ID wurde bereits vorher angefordert |
-=== Examples ===
+=== Beispiele ===
-Request Single frame with ID 0400
+Anforderung eines Einzelrahmens mit ID 0400
@@ Line 106: / Line 104: @@
-Request Single frame  (=type 00) with ID 0400 and length 3
+Anforderung eines Einzelrahmens (=Typ 00) mit ID 0400 und Länge 3
@@ Line 114: / Line 112: @@
-Request custom multi frame (=type 01) with ID 400 , length 20, sequence counter position at Byte 3 and starting value of 2
+Anforderung eines Mehrfachrahmens (=Typ 01) mit ID 400 , Länge 20, Sequenzzählerposition bei Byte 3 und einem Startwert 2
@@ Line 122: / Line 120: @@
-Request ISO-TP multiframe  (=type 02) with ID 400 (length is taken dynamically out of first frame info)
+Anforderung eines ISO-TP Multirahmens (=Typ 02) mit ID 400 (Länge wird dynamisch aus der ersten Rahmeninfo genommen)
@@ Line 130: / Line 128: @@
-==== Read Data ====
+==== Daten lesen ====
-=== Commands ===
+=== Kommandos===
-The request to the firmware to send received data to the application is done with an 22- command:
+Die Anforderung an die Firmware die empfangenen Daten zu Applikation zu übermitteln, geschieht mit dem 22- Kommando:
@@ Line 144: / Line 142: @@
-where the data byte meanings are as follows:
+in diesem bedeuten die Datenbytes folgendes:
-^  Bytes  ^  Meaning  ^  Comment  |
+^  Bytes  ^  Bedeutung  ^  Kommentar  |
-|AA BB CC DD |CAN- ID to listen to (MSB ..LSB) |  |
+|AA BB CC DD |CAN- ID die empfangen werden soll (MSB ..LSB) |  |
-As result the firmware first repeats the command + 40H (=0x62) , a four byte timestamp (AABBCCDD, FreeRTOS ticks), a one byte flag (FL)  and the received data bytes after that:
+Als Ergebnis wiederholt die Firmware das Kommando + 40H (=0x62) , einen vier Byte langen Zeitstempel(AABBCCDD, FreeRTOS ticks), einen ein Byte langen Marker (FL)  und danach die empfangenen Datenbytes:
@@ Line 157: / Line 155: @@
 AA BB CC DD FL 00 11 22 ..
 </code>
-== Flag ==
+== Marker ==
-In the moment only bit 0 of the flag is used. If set, the data output is new and has not been printed before. After printed, the flag is set to 0 by the firmware. So when bit 0 is set, this is fresh data. By that the application software don't need to control by itself (by the time stamps) if this data has already been received before or if its new data.
+Im Augenblick ist nur Bit 0 des Markers genutzt. Falls es gesetzt ist, ist der die Ausgabe neu und wurde nie zuvor gesendet. Nach dem Senden, wird der Marker wieder durch die Firmware auf 0 gesetzt. Also ist das Setzen des Bits 0 gleichbedeutend mit dem Senden von "frischen" Daten. Durch diese Maßnahme braucht die Applikation nicht zu überprüfen (Mithilfe der Zeitstempel), ob es sich um bereits empfangene oder neue Daten handelt.
-=== Errors ===
+=== Fehler ===
-the error messages are designed as General Response Code Errors, means they are coded as received bytes, not as clear text error messages. The byte sequence always starts with 7F 00, followed by the error code byte:
+Die Fehlermeldungen wurden als generelle Antwortfehlermeldungen gestaltet. Das bedeutet, daß sie als empfangene Bytes kodiert wurden und nicht als Klartextfehlermeldungen. Die Bytesequenz startet immer mit 7F 00, gefolgt von dem Fehlerkodebyte:
-^  Error Code  ^  Meaning  |
+^  Fehlerkode  ^  Bedeutung  |
-|  01  |unknown CAN ID (not configured yet) |
+|  01  |unbekannte CAN ID (noch nicht konfiguriert) |
-|  02  |no valid data received until now |
+|  02  |keine validen Daten bis jetzt empfangen |
-==== General Commands ====
+==== Allgemeine Kommandos ====
-^  Command  ^  Function  |
+^  Kommando  ^  Funktion  |
-|  p 6 1  |clear the internal data buffer list, releases all used memory buffers |
+|  p 6 1  |lösche die interne Datenspeicherliste, gibt den ganzen genutzten Speicherbereich frei |
-==== Implementation Details ====
+==== Implementations Details ====
-    - All requested CAN-IDs are internally handled as list of elements
+    - Alle angeforderten CAN-IDs werden intern als eine Liste von Elementen geführt
-    - In case a requested CAN ID is > 8 bytes, then the element needs to have two receive buffers (double buffering), to make make sure that there's always one buffer ready to read, while the other one is just in the fill process by the CAN interrupt handler.
+    - In dem Fall, wo eine angeforderte CAN ID > 8 Bytes ist, benötigt das Element zwei Empfangsspeicher (Doppelspeicher), um sicherzustellen, daß immer ein Speicher zum Lesen bereit ist, während ein anderer in den Füllprozess der CAN Interruptserviceroutine eingebunden ist.
-    - The implementation needs to make sure, that a buffer is not altered during its printout process
+    - Die Implementierung muss sicherstellen, daß ein Speicher nicht verändert wird, solange dessen Inhalt gesendet wird.
-    - The implementation needs to make sure, that a buffer is only declared as valid, if a complete frame sequence (0..x) has been received without disturbance.
+    - Die Implementierung muss sicherstellen, daß ein Speicher nur als gültig deklariert ist, wenn eine komplette Rahmensequenz (0..x) ohne Störung empfangen worden ist.
-==== Security Considerations ====
+==== Sicherheitsüberlegungen ====
+Dieses RFC-Dokument zeigt Sicherheitsaspekte auf. Sein Bedürfnis danach sicherzustellen, daß die Firmware nur im "unsichtbar empfangen" Modus auf dem Bus arbeitet ohne aktiv eine (Re)aktion auszulösen.
-This RFC raises security issues. It's need to make sure that the firmware only listens on the bus in invisible mode without creating any active (re)action on the bus.
+==== Referenzen ====
-==== References ====
+==== Adresse des Authors' ====
-==== Authors' Addresses ====
@@ Line 205: / Line 202: @@
-Phone: +49 172 410 35 98
+Mobiltelefon: +49 172 410 35 98
@@ Line 211: / Line 208: @@
-==== Appendix ====
+==== Anhang ====
@@ Line 217: / Line 214: @@
-Copyright  (C) OOBD Team (2012).  All Rights Reserved.
+Copyright  (C) OOBD Team (2012).  Alle Rechte vorbehalten.
@@ Line 247: / Line 244: @@
-The OOBD-RFC announcements are distributed via the oobd-commit-messages@googlegroups.com mailing list.
+Die OOBD-RFC Ankündigungen werden durch die oobd-commit-messages@googlegroups.com mailingliste verteilt.
-To join (or quit) the list goto [[https://groups.google.com/forum/?hl=de&fromgroups=#!forum/oobd-commit-messages|https://groups.google.com/forum/?hl=de&fromgroups=#!forum/oobd-commit-messages]]
+ Um diese zu nutzen (oder sich davon abzumelden) benutze https://groups.google.com/forum/?hl=de&fromgroups=#!forum/oobd-commit-messages
-\\