User Tools

Site Tools


de:doc:rfc_rtd-real-time-data-protocol-for-the-oobd-firmware

RTD (Real Time Data) Protokoll für die OOBD Firmware

OOBD Team S. Koehler
Anforderung zur Kommentierung:6
Obsoletes: -
Category: Draft Standard May 2013

Status dieser Nachricht

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.

Einleitung

Konzept

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

Initialisierung

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

RealTime Data Protokoll,löscht die interne PID Liste und setzt den CAN Bus in den “unsichtbar empfangen” Modus

Konfiguration

Kommandos

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.

Fehler

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

Beispiele

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

Daten lesen

Kommandos

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 ..
Marker

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.

Fehler

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

Allgemeine Kommandos

Kommando Funktion
p 6 1 lösche die interne Datenspeicherliste, gibt den ganzen genutzten Speicherbereich frei

Implementations Details

  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.

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.

Referenzen

Adresse des Authors'

Steffen Koehler

Mobiltelefon: +49 172 410 35 98

EMail:steffen@koehlers.de

Anhang

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

Updates

Obsoletes

Obsoleted-by

Updated-by

Contact

Distribution Lists

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

This website uses cookies for visitor traffic analysis. By using the website, you agree with storing the cookies on your computer.More information
de/doc/rfc_rtd-real-time-data-protocol-for-the-oobd-firmware.txt · Last modified: 2014/09/21 11:45 by wsauer