OOBD Team | S. Koehler |
Anforderung zur Kommentierung:6 | |
Obsoletes: - | |
Category: Draft Standard | May 2013 |
Diese Nachricht versorgt Dich mit Informationen wie Realtime CAN Daten durch die OOBD Firmware gelesen werden. Die Verteilung dieser Nachricht ist unbeschränkt.
Copyright (C) OOBD Team (2012). Alle Rechte vorbehalten.
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
Wähle das CAN RTD Protokoll
p 1 1 3 0
Öffnen der CAN Filter
p 8 10 1 0 p 8 11 1 0
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 |
---|
Die Daten, die empfangen werden sollen, werden von der Applikation mittels des 27- Kommando von der Firmware angefordert:
27 CanID Typ [Länge [cPos [cStart]]]
nicht angegebene Werte werden mit 0 as Default Wert vorbesetzt
in Diesem bedeuten die Datenbytes folgendes:
Block | Länge in Bytes | Bedeutung | Kommentar |
---|---|---|---|
CanID | 4 | CAN- ID die empfangen werden soll (MSB ..LSB) | |
Typ | 1 | Mehrfachrahmen Nachrichten Typ | 0: Einzelrahmen 1: Kundenspezifisch 2: ISO-TP |
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 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. |
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. |
Fehlerkode | Bedeutung |
---|---|
1 | Kommando zu lang: Es sind mehr Bytes gegeben, als durch das Kommando spezifiziert wurden |
2 | Kein Speicher mehr übrig: Es ist nicht genügend Speicher vorhanden, um den angeforderten Datensatz abzulegen |
3 | CAN ID existiert bereits: Die angeforderte CAN ID wurde bereits vorher angefordert |
Anforderung eines Einzelrahmens mit ID 0400
27 00000400
Anforderung eines Einzelrahmens (=Typ 00) mit ID 0400 und Länge 3
27 00000400 00 0003
Anforderung eines Mehrfachrahmens (=Typ 01) mit ID 400 , Länge 20, Sequenzzählerposition bei Byte 3 und einem Startwert 2
27 00000400 01 0014 03 02
Anforderung eines ISO-TP Multirahmens (=Typ 02) mit ID 400 (Länge wird dynamisch aus der ersten Rahmeninfo genommen)
27 00000400 02
Die Anforderung an die Firmware die empfangenen Daten zu Applikation zu übermitteln, geschieht mit dem 22- Kommando:
22 AA BB CC DD
in diesem bedeuten die Datenbytes folgendes:
Bytes | Bedeutung | Kommentar |
---|---|---|
AA BB CC DD | CAN- ID die empfangen werden soll (MSB ..LSB) |
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:
62 AA BB CC DD FL 00 11 22 ..
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.
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:
Fehlerkode | Bedeutung |
---|---|
01 | unbekannte CAN ID (noch nicht konfiguriert) |
02 | keine validen Daten bis jetzt empfangen |
Kommando | Funktion |
---|---|
p 6 1 | lösche die interne Datenspeicherliste, gibt den ganzen genutzten Speicherbereich frei |
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.
Steffen Koehler
Mobiltelefon: +49 172 410 35 98
EMail:steffen@koehlers.de
Copyright (C) OOBD Team (2012). Alle Rechte vorbehalten.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the OOBD Team organizations, except as needed for the purpose of developing standards in which case the procedures for copyrights defined in the Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the OOBD Team or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and THE OOBD TEAM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.“ Relation to other RFCs
Die OOBD-RFC Ankündigungen werden durch die oobd-commit-messages@googlegroups.com mailingliste verteilt.
Um diese zu nutzen (oder sich davon abzumelden) benutze https://groups.google.com/forum/?hl=de&fromgroups=#!forum/oobd-commit-messages