Part 6 named CAN_V2, CAN_BRIEF_V2, and LIN_V2 as new format versions from IEEE 1722-2025 not included in AUTOSAR. This part clarifies what actually changes in the V2 formats — and corrects an inaccuracy from Part 6: CAN_V2 and CAN_BRIEF_V2 have long been implemented in Open1722, only LIN_V2 hasn’t.

Correction to Part 6: it described CAN_V2/CAN_BRIEF_V2/LIN_V2 as a blanket "not yet implemented." In fact, Open1722 already ships CanV2.h and CanBriefV2.h — only LIN_V2 has (as of this research) no implementation yet, neither in Open1722 nor in AUTOSAR.

ACF_CAN_V2: the same content, more bus IDs

ACF_CAN vs. ACF_CAN_V2: quadlet 0 compared

The difference between ACF_CAN (chapter 9.4.1, since 2016) and ACF_CAN_V2 (chapter 9.4.3, new in 2025) is surprisingly small — and exactly for that reason practically relevant:

FieldACF_CANACF_CAN_V2

bus_id

5 bits (0-31)

11 bits (0-2047)

CAN identifier

29 bits

29 bits (unchanged)

Timestamp

64 bits

64 bits (unchanged)

BRS/FDF/ESI flags

Quadlet 0

Quadlet 3 (moved to make room for bus_id)

All functional capabilities (CAN identifier width, timestamp, CAN FD flags) stay identical between ACF_CAN and ACF_CAN_V2 — this is not a fundamentally new protocol, but a targeted bit-layout change with exactly one goal: more addressable bus IDs.

5 bits (32 bus IDs) are sufficient for most single-vehicle projects with a manageable number of CAN subnets. The need for 2048 bus IDs arises more in scenarios where a central gateway serves many different vehicle variants or platforms, each with its own CAN-subnet numbering, over a shared TSN backbone — a scenario that becomes more realistic as platform consolidation increases.

ACF_CAN_BRIEF_V2: the compact variant

Analogous to ACF_CAN_BRIEF versus ACF_CAN, ACF_CAN_BRIEF_V2 (chapter 9.4.4) drops the timestamp — with the same expanded 11-bit bus ID as ACF_CAN_V2. For event-driven CAN messages with no time relation (see the TSCF/NTSCF classification in Part 2), this is the obvious choice once more than 32 bus IDs are needed.

LIN_V2: defined, but not implemented anywhere yet

Consistently, the standard also provides for a revised LIN format version with LIN_V2 (0x23) — analogous to the CAN family. At the time of this research, though, there’s no implementation for it, neither in Open1722 nor in AUTOSAR. That’s a difference from CAN_V2/CAN_BRIEF_V2, which are at least usable in Open1722 already.

Anyone planning around LIN_V2 shouldn’t confuse it with an already available reference implementation — unlike CAN_XL (Part 7), where at least Open1722 serves as a learning environment, there’s currently no code to follow along with for LIN_V2, only the type entry in the standard itself.

Summary

AspectKey takeaway

ACF_CAN_V2

Identical content to ACF_CAN, but 11 instead of 5 bits for bus ID (2048 instead of 32 possible values) — already implemented in Open1722

ACF_CAN_BRIEF_V2

Like ACF_CAN_V2, but without a timestamp — for event-driven messages with many bus IDs

LIN_V2

Defined in the standard, but (as of this research) not implemented in either implementation

Practical relevance

Increases with the number of distinct CAN subnets a central gateway has to serve simultaneously