RV-C does not currently have a standard method of communicating and clearing stored fault information. This is a general protocol for handling this useful feature.

Entered by Martin Perlot

Friday, April 17, 2026 | 10:55am
Attachment Size
3.2.10 Stored_Fault Status.doc 63.5 KB
You must be logged in to comment. Log in
4 comments

Jennifer Tyler Member for 6 months

OBJECTION:  My team is confused on why some of the bits are not called out for byte 0 of table 3.2.10b.  Is the intention that they are n/a or should be blank, or should it be the same data as the other table and you just didn't call it out explicitly?  Also, we believe the intent of this change is just to add the change for bytes 6-7, but there was no justification called out.  You are just wanting to link a time stamp to the error?

Martin Perlot Member for 8 months 1 week

In the DM_RV, those bits are used to indicate the current device status (on/off/standby).  Leaving those unused makes it a little easier for the programmer to write his parsing routines (and therefore a little less likely to introduce a bug, we hope).  All the other bits and bytes are in the same spot, so it's safer to cut-and-paste code (and we all love to hit Ctrl-C/Ctrl-V whenever possible!)  This is a general theme throughout the specification. 

As everywhere in the protocol, the unused bits are set to 1.  Your programmers should have a habit of building each DGN starting with memset(data, 0xFF, 8);  (or the equivalent in whatever language you are using).

Bytes 6 and 7 allow an (optional) timestamp to be added to the report.  This is more fully explained in the second section (3.2.10.1).  If you want to provide a timestamp, you insert an arbitrary sequence number in those bytes, then send a TIME_STAMP DGN with the same sequence number.  If the text isn't clear, I'm open to any proposals for improvement.

Lucas Salviano Member for 1 week 6 days

Hi Martin,

We understand the proposal and the improvements that this can give to diagnostics.

But some considerations to try clarify the functionalities:

  • 5 ms as a minimum broadcast gap seems a short time to send (possibly) a lot of messages and it may overload the CAN bus. A minimum with 50 ms as multi-packet (3.2.7) frames maybe can be better here.
  • Is the idea the device storing a queue of faults or saving the latest occurrence of each fault supported?
    • If we go to the faults queue idea, we can use the Timestamp field as a faults queue index number, which can give a information about how many faults have registered on the device (since the latest registered [most recent] should be sent first).
  • As the RVC specification does not define the Diagnostic as a mode for the devices, should we limit the number of faults read per request? May send the latest X (e.g.: 10, 20) faults stored per request, and if receive a second request before a time (e.g.: 5 seconds) send the next X faults stored.
  • An option instead of sending an ACK at the end of stored faults, the device can send a STORED_FAULT_STATUS with all fields (or only timestamp/faults queue index) empty (0xFF).

Please, let me know what you think. My big concern here is maintaining an open way that someone can flood the CAN bus with a lot of messages.

Martin Perlot Member for 8 months 1 week

There's a lot to unpack here.

  • Using multi-packet frames doesn't buy us anything, traffic-wise.  You get fewer bytes/packet and if any packet is dropped the whole message is a bust.
  • As written, the onus is on the requester (a UI device) to only request the DGN as part of a user action in a diagnostic setting.  At 5ms, the DGN would use about 20% of the practical bandwidth of the network, and as Priority 7 message, all ordinary traffic will be broadcast in preference to this.  The low priority does not guarantee total safety.  Devices with limited performance and message queues can end up overwhelmed and drop incoming messages.  That's why the user trigger and diagnostic-only language is there - to protect the weak!  
    The ongoing question has always been, how much protection is enough.  The existing language (which echoes similar warnings elsewhere in the spec) is intended to prevent the user from, say, operating a slide room as all this traffic is being generated.  So the primary concern we have is whether any automated operation might be compromised (say, the synchronization of multiple smart chargers).  However, it is already incumbent on the charger manufacturers to fail safely in such circumstances, so generally the impact should be merely a brief delay in their reaction.  At worst, the particular feature might be disabled temporarily. 
    On the flip side, the slower we send the data, the longer the user has to wait for it.  So we have a trade-off between two  considerations, neither of which are all that compelling.  
    So, what's the right combination of total messages allowed and gap between them?  Gaps?  I think 50ms is too much - if timestamps are included, that's just 10/sec, and the user could be waiting an annoyingly long time.  I wouldn't argue too much about 10ms - that's 50/sec, which a user is not going to fuss too much about.  Total Messages?  Is 250 too many?  For most devices it's overkill, but we have multi-function devices that can implement dozens of lights, motors, sensors, and appliances in one box.  It's not hard to imagine such a device accumulating that many faults between visits to the service center.  I think that limit stays.
  • As a practical matter, trying to break up the transmissions into chunks is useless.   It's the bursts of traffic that matter - that's what overwhelms the low-performance units.
  • The DGNs are intended to allow any permutation of capabilities.
    • A list of every time every fault occurred (up to ~250 events), with timestamps.
    • A list of every type of fault, with the number of occurrences and the most recent timestamped.
    • A list of every type of fault, with the number of occurrences.
  • Either the blank DGN or the ACK work fine in practice, but in principle we want No Data values (e.g. FFh) to mean, "No Data".  It's a subtle distinction, but here we would be assigning meaning to a packet that otherwise would pass through the parsing routines like a ghost.  
    This actually matters if you like clean code.  For the programmer writing the parser, the blank DGN methods requires inserting the End-of-List code in the part of the parser that handles the field parsing (essentially treating the whole DGN as a field that overlaps the actual fields).  The ACK method requires putting that same code at the DGN level.   One of these is cleaner than the other.

Did I miss anything?