Table 3.3.2.a Update - Source Address Claiming
Mon, 2021-07-12 20:47 — RV-C Admin
Justification:
Table 3.3.2a is inconsistent with Table 3.2.4.3a & b, and with the text of section 3.1, which states “Messages shall use only CAN data frames in extended frame format with a DLC (Data Length) of 8.” The inconsistency was addressed elsewhere some years ago but was missed with this DGN.
Please see attached document.
| Attachment | Size |
|---|---|
| Table 3.3.2a Update 070821.docx | 14.63 KB |
I suspect though that there
I suspect though that there will indeed be cases where the RV-C is connected to a proper J1939 bus, there are many still at 250K. Case in point could be an generator with an ECU, and unless a controller is created with a bridge that will have J1939 messages transmitted, many of which are under 8-bytes.
OK, as I read your reply and explanation (thank you as always), this is my take away:
1) 4.2.2 allows for J1939 messages, even if they are less then 8 bytes.
2) In the areas where RV-C has extended J1939 (Hopefully in a compatible way) - you are looking to enforce the rest of the RV-C guidelines, including 8-byte messages.
If I am correct in this, then I remove my objection.
It seems that we are in
It seems that we are in accord.
OBJECTION ACL is part of the
OBJECTION
ACL is part of the DP=0 group of DGNs, defined by J1939 (as opposed to the extended DP=1 messages used for RV-C).
Section 4.2.2 calls out allowing J1939 compatible messages to exist (DP = 0), and there are a number of J1939 messages which do not use a DLC = 8. In addition to the ACL, the present RV-C also has other J1939 defined messages which use DCL != 8 Example: 0xEA00 (Information Request) 3 or 5 bytes - see note on single-instance vs. multi-instance
I submit section 3.1 note of DCL must = 8 should be applied only to the RV-C extensions of J1939 (ala, DP = 1), not be forced on J1939 defined messages which have a contrary definition.
Unfortunately, this ship has
Unfortunately, this ship has already sailed. The DG Request messages has long been longer than 3 bytes (see Section 3.2.4.3) due to RV-C's Instancing scheme. All we are doing with this edit is putting the two sections (3.2.4.3 and 3.3.2) into agreement.
In the first days we held out the hope that we could have true interoperability with the SAE J1939. Today that optimism seems pretty naive - J1939 doesn't even operate at the same data rate and many other incompatibilities have been written into it over the past decade-plus. All that survives of our sentiment is Section 4.2.2, which states that broadcasting J1939 messages is not a breach of section 4.2.1, which forbids undocumented messages. In other words, we accept J1939 as a data dictionary. The purpose of 4.2.1 is to prevent different products from using the same DGNs to send different data - which would have disastrous consequences. Section 4.2.1 and 4.2.2 aren't meant to supersede the DG Request and Address Claiming requirements of Section 4.1.
In a better world we could have had a higher level of compatibility with J1939. Unfortunately, the SAE was never interested in the idea - in fact, they were more than hostile to us for a while. We've salvaged what we could, and programming products to support both protocols is not terribly difficult. It requires changes to the diagnostic message, address claiming messages, heartbeat, and - let's not forget - data rate. The DG Request must already be fudged to handle RV-C Instancing, so adjusting the data length is barely any work. That's the best we can do without completely rewriting the DG Request process.
--------------------
4.2.2 SAE J1939 Compatibility
The sole exception to the prohibition in section 4.2.1 is the the use of SAE J1939 protocol, as specific care has been made by
the RV-C committee to preserve a measure of compatibility between RV-C and J1939. The SAE does not reciprocate these
efforts and some differences have been created by the SAE since the publication of the first RV-C specification, such as in the
DG_REQUEST message. It is incumbent upon the node designer to respond appropriately to any ambiguities between the two
protocols if both are operating on the data bus.