Provide only warnings for CVNs with leading or trailing binary zeros.

[ericthomasswenson]

Delete 6.1.7.2.v. (See italic text below) Rely on 6.1.7.3.c as implemented today alone

6.1.7.3.c For CVN responses from OBD ECUs, warn if 00h is observed in either the first or fourth bytes.

6.1.7.2 Fail Criteria a. Fail if total number of reported CAL IDs is < user entered value for number of emission or diagnostic critical control units (test 6.1.2). b. For responses from OBD ECUs: i. Fail if <> 1 CVN for every CAL ID. ii. Fail if CAL ID not formatted correctly (printable ASCII, padded incorrectly, etc.). iii. Fail if any received CAL ID is all FFh iv. Fail if or any CVN received is all 00h. v. Fail if CVN padded with 16-binary zeros (where either the 1st two bytes are both 00h or the last two bytes both 00h). Note HD OBD CVNs are required to be 32-bits.incorrectly (padding shall use 00h in MSB for unused bytes).

[ericthomasswenson]

This proposal was reviewed with CARB the response received says: "... the right place to make a judgment of the appropriateness of a given CRC method for a given ECU is one-on-one with each manufacturer, and not the PVE L1 standardization test. Given the high likelihood of non DEC-ECUs supporting CALID/CVN, your suggestion to downgrade to a warning for < 32-bit CVNs makes sense. Please proceed accordingly."

[ericthomasswenson]

Don’t wait for DR label here.

[battjt]

My understand is to remove

6.1.7.2.b.v Fail if CVN padded with 16-binary zeros (where either the 1st two bytes are both 00h or the last two bytes both 00h). Note HD OBD CVNs are required to be 32-bits. 6.2.7.3.d.vi Warn if CVN padded incorrectly (shall use 00h in MSB for unused bytes).

[ericthomasswenson]

Yes something needs to be done here too. Likely info for c. And d.iv.

6.1.7.3 Warn Criteria a. Warn if total number of reported CAL IDs is > user entered value for number of emission or diagnostic critical control units (test 6.1.2). b. Info if more than one CAL ID and CVN pair is provided in a single DM19 message. c For CVN responses from OBD ECUs, warn if 00h is observed in either the first or fourth bytes. d. For responses from non-OBD ECUs: i. Warn if any non-OBD ECU provides CAL ID. ii. Warn if <> 1 CVN for every CAL ID. iii. Warn if CAL ID not formatted correctly (contains non-printable ASCII, padded incorrectly, etc.). iv. Warn if any received CAL ID is all FFh v. Warn if any received CVN is all 00h. iv. Warn if CVN padded incorrectly (shall use 00h in MSB for unused bytes).

[ericthomasswenson]

CARB has accepted that some 16-bit CVNs exist in smart devices and no longer requires them to fail.

Change warnings for 00h in CVN changed to info

6.1.7.3 Warn Criteria a. Warn if total number of reported CAL IDs is > user entered value for number of emission or diagnostic critical control units (test 6.1.2). b. Info if more than one CAL ID and CVN pair is provided in a single DM19 message. c For CVN responses from OBD ECUs, info if 00h is observed in either the first or fourth bytes. d. For responses from non-OBD ECUs: i. Warn if any non-OBD ECU provides CAL ID. ii. Warn if <> 1 CVN for every CAL ID. iii. Warn if CAL ID not formatted correctly (contains non-printable ASCII, padded incorrectly, etc.). iv. Warn if any received CAL ID is all FFh v. Warn if any received CVN is all 00h. vi. Info, if CVN provides 00h in first or last byte.

[ericthomasswenson]

CARB has accepted that some 16-bit CVNs exist in smart devices and no longer requires them to fail.

Delete 6.1.7.2.b.v as shown below:

b. For responses from OBD ECUs: i. Fail if <> 1 CVN for every CAL ID. ii. Fail if CAL ID not formatted correctly (printable ASCII, padded incorrectly, etc.). iii. Fail if any received CAL ID is all FFh iv. Fail if or any CVN received is all 00h. Delete v. Fail if CVN padded with 16-binary zeros (where either the 1st two bytes are both 00h or the last two bytes both 00h). Note HD OBD CVNs are required to be 32-bits.incorrectly (padding shall use 00h in MSB for unused bytes).