The previous parts covered AVTP, ACF, and the ARXML configuration conceptually and structurally. This part shows two complete end-to-end examples — both followable with the real example programs from Open1722.

Example 1: A camera stream from capture to delivery

Camera stream: capture to deterministic delivery

As noted in Part 1: the AUTOSAR module IEEE1722Tp implements the IEEE1722TpStreamIIDC (IEC 61883/IIDC) subtype for video streaming, not CVF. Open1722 currently doesn’t ship a dedicated IIDC example, only cvf-talker/cvf-listener for the general CVF subtype of the IEEE 1722 standard. The end-to-end principle (PTP synchronization, TSN determinism, timestamp-based presentation) is the same — the concrete payload subtype in the wire format differs. The following walkthrough therefore uses cvf-talker/cvf-listener as a conceptual exercise, not a 1:1 mirror of the AUTOSAR module.

Sender side: reading video and sending it as an AVTPDU

cvf-talker reads an H.264 byte stream from stdin and packs it into CVF AVTPDUs. In practice, this is combined with GStreamer to feed in a real video source (or a synthetic test pattern for testing):

gst-launch-1.0 -e -q videotestsrc pattern=ball \
  ! video/x-raw,width=192,height=144 ! x264enc \
  ! video/x-h264,stream-format=byte-stream ! filesink location=/dev/stdout \
  | cvf-talker <args>

Prerequisite for a clean stream: the system clock must be synchronized with the NIC’s PTP hardware clock (PHC), and that clock in turn with the network’s PTP time (ptp4l, phc2sys) — otherwise the AVTP timestamp won’t agree with other participants on the network, and the "deterministic" delivery loses its foundation.

Switch side: stream identification + time-aware shaping

For the stream to actually be forwarded deterministically by the switch, it needs the mechanisms already covered in the EthSwt series:

Without both of these mechanisms in the switch, the stream remains an ordinary best-effort packet — deterministic delivery is a switch property, not purely an endpoint property.

Receiver side: presenting at the right time

cvf-listener receives the CVF AVTPDUs, waits until the presentation time encoded in the timestamp, and only then outputs the video data:

cvf-listener <args> | gst-launch-1.0 filesrc location=/dev/stdin \
  ! h264parse ! avdec_h264 ! videoconvert ! autovideosink

Deliberately waiting for the presentation time is the actual point of AVTP streaming: the receiver doesn’t display the frame the moment it arrives, but exactly at the time encoded in the header — that’s what keeps multiple synchronously running streams (e.g. surround view from four cameras) in sync in the first place.

Example 2: Transparently tunneling a CAN subnet via ACF.CAN

Tunneling a CAN subnet transparently via ACF.CAN over a TSN backbone

Unlike the camera example, this one is a direct match for the AUTOSAR ACF_CAN subtype from Part 2, since Open1722 ships a matching dedicated example for it: acf-can-talker, acf-can-listener, and acf-can-bridge.

Sender side: reading a CAN frame and tunneling it

# Reads CAN frames from a SocketCAN interface (e.g. can0) and tunnels them
# as ACF_CAN messages over the given Ethernet interface
acf-can-talker <ethernet-interface> <can-interface> <destination-mac>

Receiver side: converting ACF_CAN back into CAN

# Receives ACF_CAN messages and replays them on a local SocketCAN interface
acf-can-listener <ethernet-interface> <can-interface>

Both commands together form a unidirectional bridge (CAN bus A → CAN bus B). For bidirectional traffic, Open1722 additionally offers acf-can-bridge, which couples a local CAN interface directly and bidirectionally to an ACF stream — closer to what a real zonal gateway actually needs.

With candump on both sides and tcpdump/Wireshark on the Ethernet interface in between, you can follow the tunneling in real time: the same CAN frame shows up once on the CAN bus, and once as ACF_CAN payload inside the IEEE 1722 frame. Part 5 of this series rebuilds exactly this setup on two physical BeagleBone Black boards — but there with the Open1722 Linux kernel module instead of the user-space example applications.

Summary

ExampleKey takeaway

Camera stream (video)

AUTOSAR uses IIDC, Open1722 demonstrates the same principle only via CVF — the end-to-end flow (PTP sync, stream identification, time-aware shaping, presentation time) still carries over

CAN tunnel (ACF_CAN)

A direct match for the AUTOSAR subtype — acf-can-talker/-listener/ -bridge mirror the real ACF_CAN behavior 1:1

Determinism

Comes from the switch (stream identification + time-aware shaping) in both cases, not from the endpoint alone

Next step

Part 5 rebuilds the CAN-tunnel example as a hands-on project on two real BeagleBone Black boards — with the Open1722 kernel module instead of user-space apps

Next in the series: IEEE 1722 Part 5 — Hands-On Project: ACF-CAN Kernel Module Between Two Real BeagleBone Black Boards