Evaluate open1722 as replacement for cannelloni

[mirenz1]

Open1722 is a fork of AVNU/libavtp which is an open source reference implementation of the Audio Video Transport Protocol (AVTP) specified in IEEE 1722-2016 spec. libavtp primarily focuses on audio video data formats of the IEEE 1722-2016 spec.

IEEE 1722 is also gaining a lot of traction in the automotive community, mainly, to bridge fieldbus technologies over automotive Ethernet. In particular the AVTP Control Formats (ACF) specify serialization for a set of data formats relevant for automotive applications (e.g., CAN, LIN, etc.). Open1722 extends/modifies libavtp to also include these ACF formats.

NOTE: Open1722 is currently incubating and under active development. The APIs are not fully stable and are subject to changes.

Open1722 is under BSD License. For more information see LICENSE file.

https://github.com/COVESA/Open1722

• [ ] Build binaries for our used target platforms
• [ ] Evaluate API and how it can be integrated with EDGAR
• [ ] Prototype integration for CAN bus

[SebastianSchildt]

I think - as a first step for evaluation - replacing cannelloni with an Open1722 example executable seems quite doable

This is a bit theoretical, I do know Open1722 a bit bit but I currently have no OpenDUT setup and never compiled this stuff, so take with a grain of salt.

Basically I think the code in question for starting cannellon instances is here

https://github.com/eclipse-opendut/opendut/blob/c41a3334e59a31f28feb8473a0c5bf7345d7ec9d/opendut-edgar/src/service/cannelloni_manager.rs#L131-L149

so for a “server” if I parse it correctly it might do

cannelloni -I <SOMECAN> -S s -t <SOMETIME> -R <REMOTE_IP> -l <SOMEPORT> 

for client it does

cannelloni -I <SOMECAN>  -S c -t <SOMETIME> -R <REMOTE_IP> -r <SOMEPORT> 

Now in 1722 - also running on IP I think the example acf-can-bridge can achieve the same

One EDGAR

acf-can-bridge --canif <SOMECANA> -u -p <SOMEPORTA> --dst-nw-addr <REMOTE_IPB:SOMEPORTB> 

other EDGAR

acf-can-bridge —canif <SOMECANA> -u -p <SOMEPORTB> --dst-nw-addr <REMOTE_IPA:SOMEPORTA> 

I would hope this is "as good as cannelloni"; if not Open1722 is interested to know.

If it works, there are many options to "optimize" it, e.g. the functionality could be build/linked in directly by using Open1722 API functions. Also as this is UDP based - or if desired even its own ethertype without IP - MAYBE by using multicast groups or MAC addresses some efficiency might be gained in some situations, but I think that is more of a general networking nut to crack (how would the GRE/wireguard setup play with this? At what points would/should the packets be duplicated for best efficiency/performance)

Just dropping support via the exmaple bridge would already give

• a standardized way to encapsulate CAN in Ethernet (whether that has any "worth" is of course in the eye of the beholder)
• As it as expected to see this technology also in "real ECUs", it makes it easier in a mixed HIL/SIL setup to integrate real ECUs in the OpenDUT setup

Also pinging @nayakned

[SebastianSchildt]

Would also solve/make #251 obsolete, as Open1722 is BSD licensed

[mbfm]

Thanks for the pointers, that does make it a lot more concrete what we'll actually need to do for trying it out. We'll hopefully have time to try this out sometime soon.

[hafklin]

I claimed this issue for now, as someone from our side will be working on this soon.