Lead Group : Level One Profile
Fri, 2020-02-21 00:43 — Martin Perlot
From the Lead Group,
The Level One testing profile. Level One compliance indicates that the device can coexist with other products on an RV-C network, and is the lowest level of compliance being considered.
| Attachment | Size |
|---|---|
| Level One Profile.pdf | 87.76 KB |
An addition regarding Device
An addition regarding Device Independence
---------------------------
To the description of the Profile 01A, add:
"All tests assume that the device being tested is operating independently of any other device, save as specifically called out in the test. A product is not considered compliant if it requires another specific device to be present on the network."
-----------------
Justification:
Without such a requirement, it may be possible for non-compliant products to "fake" compliance with the help of a more sophisticated device. For example, a second device might be programmed to translate commands or requests on the behalf of the device being tested. A device that requires such assistance could not reasonably be called compliant.
Edit
Edit required:
----------------------
"In all tests (at all levels) requiring the device to respond to a specific RV-C message, the Priority and Source Address of that message shall be arbitrary, unless specifically stated otherwise in the test description."
In addition, an amendment to section 3.2, which currently says:
"Due to the bus arbitration method used in the CAN data link layer protocol the use of the priority bits and the SA bits are limited. When two RV-C nodes attempt to transmit simultaneously, the priority bits determine which message will get on the bus first. All RV-C nodes shall have a unique source address, which is the tiebreaker-of-last-resort."
Replace this with:
"The priority bits and SA bits are essential for bus arbitration. When two RV-C nodes attempt to transmit simultaneously, the priority bits determine which message will get on the bus first. And as all RV-C nodes have a unique source address, the SA serves as the transmission tiebreaker-of-last-resort. In general, receiving nodes are to ignore these fields. These fields are not to be used for any other purpose, and in particular they are not to be parsed as meaningful data, except as specifically described in certain specialized applications."
------------------
Justification:
Section 3.2.1.1 states already explicitly that the source address "shall not be used by other RV-C nodes to interpret data from that node . . . " except in specific circumstances. As most RV-C networks use dynamic addressing extensively, source addresses may shift unpredictably and should not be used in normal operation. This is also a key reason why proprietary messages are not allowed in ordinary operations, as proprietary messages depend on stable source addresses.
The document is not as clear with regards to Priority. Experience has shown that it's a common mistake for designers to parse the priority bits as though they were a meaningful part of the DGN. However, this breaks their products instantly whenever the committee makes a change in a message priority. Some additional guidance would be valuable.