User Tools

Site Tools


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

This is an old revision of the document!


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

Concept

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 einzuschliessen wenn Echtzeitdaten in OOBD aufgenommen werden, 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

     - 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

Initialization

Select the CAN RTD protocol

p 1 1 3 0

Open the CAN filters

p 8 10 1 0
p 8 11 1 0

This activates the CAN Real Time Protocol, clears the internal PID list and sets the CAN bus into “invisible listen” mode

Configuration

Commands

The data to listen to is defined by the application to the firmware with an 27- command:

27 CanID Type [Length [cPos [cStart]]]

Values not given use 0 as default value

where the data byte meanings are as follows:

Block Length in Bytes Meaning Comment
CanID 4 CAN- ID to listen to (MSB ..LSB)
Type 1 Multi frame message type 0: Single Frame
1: Custom
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)
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.
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.

Errors

Error Code Meaning
1 Command too long: there are more bytes gives as specified by the command format
2 out of Memory: Not enough memory to store the requested data buffer
3 CAN ID already exist: The requested CAN ID is already requested before

Examples

Request Single frame with ID 0400

27 00000400

Request Single frame (=type 00) with ID 0400 and length 3

27 00000400 00 0003

Request custom multi frame (=type 01) with ID 400 , length 20, sequence counter position at Byte 3 and starting value of 2

27 00000400 01 0014 03 02

Request ISO-TP multiframe (=type 02) with ID 400 (length is taken dynamically out of first frame info)

27 00000400 02

Read Data

Commands

The request to the firmware to send received data to the application is done with an 22- command:

22 AA BB CC DD

where the data byte meanings are as follows:

Bytes Meaning Comment
AA BB CC DD CAN- ID to listen to (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:

62 AA BB CC DD FL 00 11 22 ..
Flag

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.

Errors

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:

Error Code Meaning
01 unknown CAN ID (not configured yet)
02 no valid data received until now

General Commands

Command Function
p 6 1 clear the internal data buffer list, releases all used memory buffers

Implementation Details

  1. All requested CAN-IDs are internally handled as list of elements
  2. 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.
  3. The implementation needs to make sure, that a buffer is not altered during its printout process
  4. 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.

Security Considerations

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.

References

Authors' Addresses

Steffen Koehler

Phone: +49 172 410 35 98

EMail:steffen@koehlers.de

Appendix

Copyright (C) OOBD Team (2012). All Rights Reserved.

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

The OOBD-RFC announcements are distributed via the oobd-commit-messages@googlegroups.com mailing list.

To join (or quit) the list goto 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.1411229371.txt.gz · Last modified: 2014/09/20 18:09 (external edit)