Short answer is: almost certainly the ECU can not distinguish these two messages.
DBC is not a public format, it is proprietary format of Vector so this answer, and usually any answer, is only based on partial discosure from Vector examples, experience and well established DBC-friendly public tools like cantools
.
Usually this dbc rules get written like this
BO_ 1 BCS_Vout: 8 HIL
SG_ Vout_01 : 0|15@1+ (4,800) [0|32767] "mV" BCS
BO_ 1 BCS_Load: 8 HIL
SG_ Load_01 : 0|15@1+ (5,0) [0|32767] "mA" BCS
I am not sure that they are strictly DBC format compliant, putting BO_
and SG_
in the same rows, but I experimented myself that (maybe tolerant) tools like cantools
accept it both ways.
You can test the resulting DBC file (with the five line at the start of this answer or the three lines in the question)
$ cat 497070.dbc
BO_ 1 BCS_Vout: 8 HIL SG_ Vout_01 : 0|15@1+ (4,800) [0|32767] "mV" BCS
BO_ 1 BCS_Load: 8 HIL SG_ Load_01 : 0|15@1+ (5,0) [0|32767] "mA" BCS
with such tool and your suspects are confirmed, the two definitions override each other
$ echo " can0 1 [8] 31 00 FA 01 D6 00 00 45" | cantools decode 497070.dbc
Overwriting message 'BCS_Vout' with 'BCS_Load' in the frame id to message dictionary because they have identical masked frame ids 0x1.
can0 1 [8] 31 00 FA 01 D6 00 00 45 ::
BCS_Load(
Load_01: 245 mA
)
where:
- file name
497070
is irrelevant for the test and is the actual id of this question
- message
can0 1 [8] 31 00 FA 01 D6 00 00 45
match the dbc rules because it has arbitration id 1
and the specified 8 byte of message length, message data bytes are close to random, interface name can0
, again, is irrelevant
cantools
explains that the rules overlap and the last one win so the message is decoded as a Load_01
signal
Using multiplexing technique it is possible to have one of this two DBC rules triggered by another "unused" part of the message, but this is not the case because an additional field should be present, like this
BO_ 1 BCS_Vout: 8 HIL
SG_ Vout_01 m<some-value> : 0|15@1+ (4,800) [0|32767] "mV" BCS
for instance
BO_ 1 BCS_Vout: 8 HIL
SG_ Vout_01 m322 : 0|15@1+ (4,800) [0|32767] "mV" BCS
which is not.
Further analysis probably requires taking into consideration the complete DBC file and some CANBUS data dump.