-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate if signal names may be reused in DBC files #8
Comments
This issue has been migrated from eclipse-kuksa/kuksa.val.feeders#122. Please see that issue for older comments. |
This was referenced Jan 22, 2024
sophokles73
added a commit
to boschglobal/kuksa-can-provider
that referenced
this issue
Jan 22, 2024
During startup, the DBC Feeder reads in CAN message definitions from arbitrary database files. When using the same signal name in different message definitions, care needs to be taken that the semantics of the signal are the same across all messages.
sophokles73
added a commit
to boschglobal/kuksa-can-provider
that referenced
this issue
Jan 22, 2024
During startup, the DBC Feeder reads in CAN message definitions from arbitrary database files. When using the same signal name in different message definitions, care needs to be taken that the semantics of the signal are the same across all messages.
sophokles73
added a commit
to boschglobal/kuksa-can-provider
that referenced
this issue
Jan 22, 2024
During startup, the DBC Feeder reads in CAN message definitions from arbitrary database files. When using the same signal name in different message definitions, care needs to be taken that the semantics of the signal are the same across all messages.
erikbosch
pushed a commit
that referenced
this issue
Jan 23, 2024
During startup, the DBC Feeder reads in CAN message definitions from arbitrary database files. When using the same signal name in different message definitions, care needs to be taken that the semantics of the signal are the same across all messages.
Closed by #9 |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A CAN database consist of a number of messages, each containing a number of signals. At the moment the DBC Feeder design is based on the assumption that signal names are unique. We should better investigate if that is true, or be prepared that it maybe is not always true. According to https://support.vector.com/kb?id=kb_article_view&sysparm_article=KB0011320&sys_kb_id=4ae40ea41b2614148e9a535c2e4bcba7&spa=1 it seems names may be reused in different frames.
A few possible solutions:
Alt 1: Treat it as a limitation
State that behavior if there are multiple signals with the same name is undefined. We could refactor
get_canid_for_signal
so that it the first time it search for a signal name does not stop when finding first match, but rather continue and give a warning or error if it finds a second instance. So if you do not get a warning or error you are fine.Alt 2: Mandatory message name
Make message name mandatory in the mapping, make sure it matches.
Alt 3: Optional message name
Only require message name if there are conflicts. I.e. if there are 2+ signals with same name give an error if no message name has been specified. if a message name has been specified verify that it match
The text was updated successfully, but these errors were encountered: