Making CAN-protocol adapter the new "default" CAN Provider TODO list

[SebastianSchildt]

The current KUKSA CAN provider is quite flexibly and based on Python: https://github.com/eclipse-kuksa/kuksa-can-provider/tree/main

Then current issue with it it, that it can generate high CPU loads with lot's of CAN traffic, and outside of (pre-)development you may not want to deploy Python code to a vehicle.

So we can use this issue to track/discuss the goals we think the RUST provider needs to hit to be considered the new "default" option (and the potentially inheriting the old repo as well).

In a nuthshell, it is ready if it "can do everything the old provider can"+x .

This includes:

• Being able to read from any socketcan device and configure mapping of "simple" CAN messages
  • Basically this means being able to process the tesla log in the current CAN provider and reading the config from an overlay file (https://github.com/eclipse-kuksa/kuksa-can-provider/blob/main/mapping/README.md)
  • The basic mechanism should be the same. I guess whether the syntax/features of the overlay changes could be discussed
  • Should still support DBC Files. Either like it is now, having a two step process: Applying DBC transformations first, and applying any further transformations to VSS in a second step, or alternatively as something that can "import"DBC transformations for further modifications into an overlay
• Have some (integration) tests in CI
• Optional but nice: Support some J1939, also admittedly the support in current CAN provider is quite barebone (https://github.com/eclipse-kuksa/kuksa-can-provider/blob/main/doc/j1939.md)
• Being buildable/deployable as container
• Provide basic support to write to CAN (@erikbosch I think we can do that right? Do we have docs for that?)
• Should support TLS connections to databroker (https://github.com/eclipse-kuksa/kuksa-can-provider/blob/main/doc/configuration.md)
  • Maybe here the upcoming Rust SDK can help. https://github.com/eclipse-kuksa/kuksa-rust-sdk , but lets not be blocked by this (@wba2hi )

fyi @RaviprasadBS @ManjukiranVALEO

[RaviprasadBS]

@SebastianSchildt Thank you for bringing this up. We agree that implementing this feature will enhance the usability of the can-protocol-adapter. We will plan and discuss the necessary changes with the team to move forward.

We will keep the issue updated with progress and are happy to discuss further details as needed. If we have any questions regarding the feature, we will reach out for clarification.