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

1. 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
2. Um unvorhersehbare Bus-Geschwindigkeit Engpässe zu vermeiden, werden die Daten nur in der Firmware gesammelt und nur auf Anfrage übergeben.
3. 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

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

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:

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:

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:

1. Alle angeforderten CAN-IDs werden intern als eine Liste von Elementen geführt
2. 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.
3. Die Implementierung muss sicherstellen, daß ein Speicher nicht verändert wird, solange dessen Inhalt gesendet wird.
4. 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.

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