The previous five parts covered AVTP, ACF, and the ARXML configuration of the AUTOSAR module IEEE1722Tp — and repeatedly noted that AUTOSAR only implements a slice of what the general IEEE 1722-2025 standard actually describes. This part makes that slice explicit: which AVTPDU subtypes and ACF message types does the standard know that simply don’t appear in the AUTOSAR module (as of R24-11)?

This is based on the header files from COVESA/Open1722 (include/avtp/CommonHeader.h, include/avtp/acf/AcfCommon.h, and the individual ACF format headers), each of which explicitly cites concrete chapters of the IEEE 1722-2025 text — the most reliable freely available source, since the standard’s full text itself is paywalled (see Part 1).

AVTPDU subtypes: the full standard vs. the AUTOSAR module

AVTPDU subtypes: full standard vs. AUTOSAR module
SubtypeValueIn the AUTOSAR module?

61883_IIDC

0x00

Yes — IEEE1722TpStreamIIDC

MMA_STREAM

0x01

No

AAF

0x02

Yes — IEEE1722TpStreamAAF

CVF

0x03

No — as noted in Part 1: AUTOSAR uses only 61883_IIDC for video

CRF

0x04

Yes — IEEE1722TpStreamCRF

TSCF

0x05

Yes — as a frame for ACF messages (see Part 2)

SVF

0x06

No

RVF

0x07

Yes — IEEE1722TpStreamRVF

AEF_CONTINUOUS / VSF_STREAM / EF_STREAM

0x6E / 0x6F / 0x7F

No

NTSCF

0x82

Yes — as a frame for ACF messages (see Part 2)

ESCF / EECF / AEF_DISCRETE

0xEC / 0xED / 0xEE

No

ADP / AECP / ACMP / MAAP

0xFA / 0xFB / 0xFC / 0xFE

No

ADP, AECP, ACMP, and MAAP aren’t streaming formats — they’re the AVDECC control protocols (discovery, enumeration/control, connection management, MAC address assignment) from the consumer AV space (professional audio/video networking). AUTOSAR not covering these isn’t a gap in the meaningful sense — automotive ECUs aren’t configured via AVDECC discovery, but via ARXML at design time. The remaining gaps (CVF, SVF, MMA_STREAM, AEF_*, VSF_STREAM, EF_STREAM, ESCF, EECF), on the other hand, are genuine streaming formats AUTOSAR simply hasn’t specified (yet).

ACF message types: Table 22 in detail

ACF types: AUTOSAR subset vs. full standard

The ACF type list (Avtp_AcfMsgType_t in AcfCommon.h, cited against "IEEE Std 1722-2025 table 22") is considerably richer than Part 2 suggested. Four groups can be distinguished:

In the AUTOSAR module

TypeValue

CAN (+ CAN_BRIEF)

0x1 (+ 0x2)

LIN

0x3

Already in IEEE 1722-2016, but not in AUTOSAR

TypeValueNote

FLEXRAY

0x0

Implemented by Open1722 (FlexRay.h), not by AUTOSAR IEEE1722Tp

MOST

0x4

Also in the standard since 2016, also not in AUTOSAR

GPC (Generic Pipe Content)

0x5

Generic tunnel for arbitrary pipe/stream data with no dedicated format

SENSOR / SENSOR_BRIEF

0x8 / 0x9

Generic sensor data packet tunneling

New in IEEE 1722-2025, not in AUTOSAR

These are the actually interesting additions — formats that didn’t exist at all in the 2016 revision:

TypeValueNote

CAN_XL (chapter 9.4.18)

0x11

Tunnels CAN-XL frames — including a VCID (Virtual CAN Network ID) and SEC field, both CAN-XL-specific concepts that don’t exist for classic CAN/CAN FD (details in Part 7)

CAN_XL_BRIEF (chapter 9.4.19)

0x12

Reduced header for CAN-XL, analogous to CAN_BRIEF for classic CAN

CAN_V2 (chapter 9.4.3) / CAN_BRIEF_V2 (chapter 9.4.4)

0x21 / 0x22

New, revised format versions with a considerably wider bus-ID field (11 instead of 5 bits) — already implemented by Open1722 (CanV2.h, CanBriefV2.h), see Part 8

LIN_V2

0x23

Present in the standard’s type enum, but (as of this research) not yet implemented in either implementation (Open1722, AUTOSAR)

BYTE_BUS / GBB (chapter 9.4.14)

0xD

Generic Byte Bus — a tunnel for arbitrary byte-array protocols with request/response semantics (see Part 9)

BYTE_BUS_BRIEF / ABB (chapter 9.4.15)

0xE

Abbreviated Byte Bus — a variant of GBB without the timestamp field (see Part 9)

GISF (chapter 18)

0xC

Generic Image Sensor Format — its own chapter in the standard, for raw image data straight from the image sensor (not to be confused with RVF or 61883_IIDC, which already transport compressed/processed video frames)

CAN_XL is the practically most relevant gap for a modern zonal architecture project: CAN-XL itself (up to 2048 bytes of payload per frame, VCID for virtual network segmentation) is gaining traction in new E/E architectures precisely because it bridges classic CAN and Ethernet-scale bandwidth. An AUTOSAR project that wants to tunnel CAN-XL subnets via ACF currently can’t do so through the standard IEEE1722Tp mechanism.

Implemented in neither Open1722 nor AUTOSAR

TypeValue

SERIAL

0x6

PARALLEL

0x7

AECP (as an ACF type, distinct from the identically-named AVTPDU subtype usage)

0xA

ANCILLARY

0xB

I2C / I2C_BRIEF

0xF / 0x10

CHECKSUM / CRC

0x76 / 0x77

Vendor-specific (USER_FIRST–USER_LAST)

0x78–0x7F

The vendor-specific range (0x78–0x7F) is exactly where community extensions beyond the standard operate — COVESA, for instance, maintains its own VSS ACF format in Open1722 (Vehicle Signal Specification, under include/avtp/acf/custom/) for tunneling VSS signals. This is explicitly not part of IEEE 1722-2025 itself, but a COVESA-specific convention within the range the standard reserves for exactly that purpose.

Why these gaps (probably) exist

None of the gaps listed are surprising once you consider the context AUTOSAR CP R24-11 was specified in:

ReasonAffects

Release timing

CAN_XL, CAN_XL_BRIEF, GBB, ABB, GISF are additions from IEEE 1722-2025 — an AUTOSAR release specified before these chapters were finally standardized simply can’t contain them yet

Missing automotive use case (so far)

SERIAL, PARALLEL, I2C target generic embedded bus tunneling rather than established vehicle field buses — less pressure to add them to an automotive BSW module in the short term

No automotive use case (fundamentally)

ADP/AECP/ACMP/MAAP belong to the AVDECC ecosystem for consumer AV device discovery — ARXML-based design-time configuration makes runtime discovery in an ECU unnecessary

None of this is a guarantee that a future AUTOSAR release will add these formats — it’s merely a plausible explanation for why they’re currently missing. Anyone depending on one of these types (CAN_XL above all) should explicitly raise it with AUTOSAR as an extension request, not count on automatic inclusion in the next release.

Summary

AspectKey takeaway

AVTPDU subtypes

AUTOSAR covers 6 of roughly 19 subtypes (61883_IIDC, AAF, CRF, TSCF, RVF, NTSCF) — the AVDECC subtypes are irrelevant for automotive, the rest (CVF, SVF, MMA_STREAM, …​) are genuine gaps

ACF types

AUTOSAR only covers CAN/CAN_BRIEF/LIN — FlexRay/MOST/GPC/ Sensor (since 2016) and CAN-XL/GBB/ABB/GISF (new since 2025) are missing entirely

Most practically relevant gap

CAN_XL — for modern zonal architectures with higher per-message bandwidth needs

What AUTOSAR doesn’t need

The AVDECC control protocols (ADP/AECP/ACMP/MAAP) — runtime discovery contradicts the ARXML design-time model

The following three parts go into the practically most relevant gaps in detail: CAN-XL, CAN_V2/LIN_V2, and Generic/Abbreviated Byte Bus.

Next in the series: IEEE 1722 Part 7 — CAN-XL & CAN-XL Brief