DBC signal multiplexing across multiple CAN frames for Cyphal?

Development & Maintenance Specification
1

I have a use case of quite a long Cyphal message which is split across multiple CAN frames. Is it possible to parse such message by using DBC format, i.e. multiplexing of signals like for J1939 or CANOpen?

2

@pavel.kirienko and @scottdixon - any thoughts on this use case of DBC signal multiplexing across multiple CAN frames? Please note, it is for the major Cyphal customer and is a blocker for a critical product launch…

3

We lack enough definition to comment directly here but I’ll attempt to guess at the questions:

…a long Cyphal message which is split across multiple CAN frames.

Of course, yes, Cyphal supports breaking up long messages across multiple CAN frames. Since it’s inception that has been a primary use case and remains a first-class feature on all supported transports.

…parse [a multi-part Cyphal message] by using DBC format?

Well…no? I mean, dsdl is similar to CAN database files in that it is a textual formal describing how to interpret data received over CAN however it is not compliant with CANOpen nor J1939 formats for DBCs. You could embed CANOpen, J1939, or anything really; as a binary blob but that’d be a lot of complexity to deal with since Cyphal would support everything you needed natively and without the additional overhead that comes with tunneling a protocol.

…i.e. multiplexing of signals like for J1939 or CANOpen?

Again, Cyphal is not compliant with J1939 nor CANOpen specifications but DSDL messages allow for similar if more advanced “multiplexing” in that DSDL messages are composable. So, if you call a given set of DSDL messages “signals” and then compose them into a single DSDL message you call a “message signal” you will have “multiplexed signals”. Because DSDL doesn’t make any such distinctions between signal and message all DSDL defined types can be considered to support Extended Signal Multiplexing.

4

Well, my understanding on DBC support for parsing long Cyphal/CAN messages is also: “NO, no supported”. Just to rephrase the original question and the use case scenario:

  1. There are already long (multi-frame) Cyphal messages on a CAN bus.
  2. A device is connected to the CAN bus to just listen and parse those long Cyphal messages.
  3. The device can NOT use DSDLs nor Nunavut. The device has only DBC format supported for parsing CAN messages.
  4. It looks there is NO way for the device to parse those long Cyphal messages whatever we do in the DBC definition. I.e. Cyphal multi-frame long messages are NOT compatible with the DBC format.

Is my understanding correct?

5

Correct. DBC is defined by a completely different standard. Cyphal is not CANOpen nor is it J1939. Cyphal is a distinct standard that supports more complex data types than is typically found in Automotive ECUs.

Now, that said, my understanding of DBC is that is does not govern how to reassemble multi-part messages. That’s a lower-layer concept and DBC interpretations would be applied to reassembled messages – I think. Once you have a reassembled message, however, there’s a chance that a subset of Cyphal language features may be shared with a subset of supported DBC concepts. Specifically; sealed Cyphal messages composed only of individual integer types (i.e. no arrays) could be described using the DBC format by creating Little-endian Signals for each field in the message. Obviously this would require Cyphal messages that were hand-tailored to be compatible and, again, would only apply to the message after it was reassembled by a fully Cyphal-compliant transport implementation.

6

Thanks, Scott, great update and clarification.
@pavel.kirienko Can you provide your feedback on this DBC request as well? Any chances to use DBC only for parsing multiframe Cyphal/CAN messages?