Part 1 introduced AVTP as a frame format for audio/video streaming. This part covers its own AVTPDU subtype that’s at least as relevant for automotive applications: ACF (AVTP Control Format).
This series originally scoped ACF as a generic field-bus tunneling mechanism
for practically any bus system — that assumption came from the Open1722
reference implementation. A look at the actual AUTOSAR specification
( |
The ACF format family: AUTOSAR module vs. the general standard
| ACF format | Specified in the AUTOSAR module IEEE1722Tp (R24-11)? |
|---|---|
ACF_CAN (incl. the CAN_BRIEF variant) | Yes — container |
ACF_LIN | Yes — container |
CAN-XL / CAN-XL Brief, FlexRay, MOST, Sensor, GPC, Generic Byte Bus, GISF | No — the general IEEE 1722 standard and the Open1722 reference implementation know these formats, but the AUTOSAR module `IEEE1722Tp’s configuration specification (as of R24-11) provides no dedicated container for them |
That doesn’t mean FlexRay or MOST tunneling over TSN is impossible in
general — just not via the standard AUTOSAR mechanism |
Open1722 still remains the right choice as a learning environment: it implements the general IEEE 1722 standard directly (not the AUTOSAR abstraction on top of it), and is excellent for reproducing ACF-CAN and ACF-LIN tunneling hands-on — see Parts 4 and 5 of this series. It’s important, though, not to confuse the two layers (the general standard/Open1722 vs. the concrete AUTOSAR BSW module). |
TSCF vs. NTSCF: the key framing difference
ACF messages aren’t sent directly as an AVTPDU, but transported inside one of
two control-format frames. In the ARXML, this is selected via the
enumeration parameter IEEE1722TpStreamAcfHeaderType:
TIME_SYNCHRONOUS (TSCF) | NON_TIME_SYNCHRONOUS (NTSCF) | |
|---|---|---|
Spelled out | Time Sensitive Control Format | None Time Sensitive Control Format |
AVTP stream data subtype |
|
|
Timestamp | Carries a valid | No timestamp (field reserved/ignored) |
Typical use | Time-critical data — e.g. clock-synchronous sensor/control data | Event-driven data — e.g. sporadic CAN/LIN messages with no time relation |
Overhead | Slightly higher (timestamp field + maintaining it on the sender side) | Minimal |
The choice between TSCF and NTSCF isn’t a property of the field-bus message itself, it’s a per-ACF-stream configuration decision: the same CAN message can be tunneled via TSCF or NTSCF depending on the project — TSCF only pays off when the timestamp is actually evaluated on the receiving side. |
Bundling multiple field-bus messages in one AVTPDU
A single TSCF or NTSCF packet can bundle multiple ACF messages — in the
AUTOSAR module, this is controlled concretely via three parameters on the
IEEE1722TpStreamACF container:
| Parameter | Meaning |
|---|---|
| Boolean switch: may CAN and LIN messages be collected mixed into one ACF
stream ( |
| A size threshold in bytes — once exceeded, this triggers sending the collected ACF packet |
| A timeout in seconds — also triggers sending, regardless of whether the threshold was reached |
The Open1722 example from its README shows the same principle at the API level (simplified, from the general reference implementation, not the AUTOSAR API itself):
Avtp_Tscf_Init(&tscf_pdu);
Avtp_Tscf_SetTv(&tscf_pdu, 1);
Avtp_Tscf_SetAvtpTimestamp(&tscf_pdu, timestamp);
/* first ACF message: CAN frame */
Avtp_Can_Init(&can_msg);
Avtp_Can_SetCanBusId(&can_msg, 1);
/* ... fill in CAN payload ... */
/* second ACF message: LIN frame, in the same AVTPDU */
Avtp_Lin_Init(&lin_msg);
/* ... fill in LIN payload ... */
/* both messages are written back-to-back into the same TSCF payload
before the packet is sent */Bundling significantly reduces the Ethernet overhead per field-bus frame —
especially for small LIN/CAN payloads, a dedicated Ethernet frame per
field-bus message would be disproportionately inefficient. The downside: an
|
Why this matters for zonal architectures
The actual use case for ACF in the vehicle: a zonal architecture where not
every ECU immediately migrates to native TSN Ethernet. Legacy subnets (CAN,
LIN — within what IEEE1722Tp covers today) stay local within a zone, but
the zonal controller transparently tunnels their traffic over the central
TSN backbone to a domain controller or a central compute unit — without the
field-bus ECUs themselves needing any changes.
| Migration stage | Role of ACF |
|---|---|
Fully migrated | ECU speaks native Ethernet/AVTP directly — no ACF needed |
Partially migrated (the typical case today) | Zonal controller tunnels CAN/LIN subnets via ACF over TSN — field-bus ECUs remain unchanged |
Not migrated | Classic field bus with no Ethernet connectivity at all |
This intermediate ("partially migrated") stage tends to be the norm for years in practice, because migrating every ECU of a vehicle platform to Ethernet all at once is rarely economically sensible. Part 5 of this series makes exactly this scenario concretely reproducible on two physical BeagleBone Black boards.
Summary
| Aspect | Key takeaway |
|---|---|
ACF in the AUTOSAR module |
|
TSCF vs. NTSCF | Correctly spelled out: Time Sensitive Control Format (subtype |
Bundling |
|
Zonal relevance | ACF is the mechanism partially migrated vehicle architectures use to transparently integrate CAN/LIN subnets over a central TSN backbone |
Next step | Part 3 covers the complete ARXML configuration of the |
Next in the series: IEEE 1722 Part 3 — ARXML Configuration of the IEEE1722Tp Module