Multiple CAN bus isolation in DBC CAN provider

[raksac]

For a system design with multiple (zonal) CAN bus topology, what would be the recommended method of providing similar isolation in the DBC CAN provider running as a docker container.

Reading up the code(config/dbcfeeder.ini) the port definition in [CAN] section has a single virtual can port (socketcan). Converting the port into a list (one or more comma separated ports) and the config parsing handler can easily enable multiple vcan ports be used rather than spanning multiple containers with the --canport argument. Happy to create a PR if there is interest in looking at the solution. Thanks in advance

[erikbosch]

I think support of multiple can-ports would be a great addition. I am no expert in this area - so I do not know how a zonal topology typically works from a CAN perspective, like do you typically have separate DBC-files, or does the Python CAN stack handle this "invisibly"? One also need to consider implications on the the DBC-mapping, if any. Like if we specify DBC signal name, will the CAN stack automatically direct it to right bus, or do we need some mechanism to map DBC-name to a specific bus, especially for the scenario when sending a CAn message.

I see no problem if we only support use-cases, but we shall at least know which use-cases we do not support so that we possibly can give an error.

[raksac]

Thanks @erikbosch for replying. I like your idea of supporting use-cases so let's start with a simple one. In a zonal ECU style architecture (say the prominent ones eg: infotainment, instrument cluster, body controls etc) typically the signal routing get some guarantees of isolation, prioritization, safety etc by the designer. Likewise when the software stack requires similar guarantees, using different socket can interface (optionally) paired with CAN bus specific DBC-mapping provides similar outcome as seen with the underlying physical/hardware.

This proposal does not (and in my opinion is beyond scope) assure data integrity of dbc2val conversion which maybe affected by the collision of CAN Id(s) routed on different socket can interfaces to DBC-mapping.

I am happy to create a PR and get some comments

[fpetry]

I'm also very interested in multiple configurable can ports in one KUKSA can provider.

I think it could look like sections in the config file, where the configuration for each bus is given separately:

[can.1]
port = vcan0
j1939 = False
dbcfile = /path/to/dbcfiles/dbcfile.dbc
dbc_default_file = dbc_default_values.json

[can.2]
port = can0
j1939 = False
dbcfile = /path/to/dbcfiles/anotherdbcfile.dbc
dbc_default_file = other_dbc_default_values.json