Part 6 named BYTE_BUS/GBB and BYTE_BUS_BRIEF/ABB as further 2025 additions not included in AUTOSAR. Unlike CAN_XL (Part 7) or CAN_V2 (Part 8), GBB/ABB don’t tunnel a concrete field-bus protocol — they’re a generic frame for bus systems that don’t (yet) have their own ACF format.

What GBB/ABB are meant for

ACF_GBB (Generic Byte Bus, chapter 9.4.14) and ACF_ABB (Abbreviated Byte Bus, chapter 9.4.15) don’t carry field-bus-specific semantics like ACF_CAN or ACF_LIN — instead, they model a generic request/response transaction scheme that can be mapped onto arbitrary byte-oriented bus protocols.

The exact meaning of individual header bits (hs, cs, op, rsp, err) can only be inferred from the field names themselves in the freely available source code, not from a detailed description — the full text of chapter 9.4.14 of the standard is paywalled. The following classification is therefore a plausible, but not conclusively verified, interpretation of the field names.

Header fields at a glance

ACF_GBB vs. ACF_ABB: the same transaction header
FieldWidthPresumed meaning (from the field name)

byte_bus_id

11 bits

Identifies the bus instance — same width as CAN_V2/CAN_XL (see Parts 7 and 8)

message_timestamp

64 bits (GBB only)

As with CAN/CRF — the transaction’s time reference

evt

4 bits

Event/message type within the generic transaction

hs

1 bit

Handshake flag — presumably confirms a bus transaction at the protocol level (analogous to an ACK bit)

cs

1 bit

Chip-select flag — hints at a target audience of SPI-like bus protocols with a physical chip-select line

transaction_num

8 bits

A correlation ID to unambiguously match a response to its request

op

1 bit

Operation — presumably read vs. write access

rsp

1 bit

Marks the message as a response (rather than a request)

err

1 bit

Error flag for the transaction

ms

1 bit

"More Segments" — as with CAN_XL (Part 7): segmentation for transfers that don’t fit into one ACF message

read_size/segment_num

12 bits

A dual-purpose field — the requested size on a read request, the segment number on a (fragmented) response

The interplay of op/rsp/err/transaction_num reads like a classic request/response bus protocol (request, respond, report errors, correlate request and response by ID) — similar to the pattern known from SPI or I2C transactions with an address/data cycle, just kept protocol-agnostic.

ACF_ABB: the same structure without a timestamp

ACF_ABB carries exactly the same transaction fields as ACF_GBB, but drops message_timestamp — the same pattern as CAN/CAN_BRIEF or CAN_XL/CAN_XL_BRIEF. For generic bus transactions where no time relation is evaluated, that saves eight bytes per message.

Why this matters for niche automotive protocols

In practice, a zonal controller occasionally runs into bus systems for which there’s no established ACF format — whether that’s a vendor-specific diagnostic protocol, a sensor with a proprietary register access scheme, or a legacy protocol from a bought-in module. GBB/ABB provide a way out for exactly this case, without having to wait for a dedicated ACF format to be standardized first.

GBB/ABB are a generic fallback, not a replacement for a dedicated format. Where a specific ACF format exists (CAN, LIN, FlexRay, MOST, …​), it should be used — the field-bus-specific semantics (e.g. CAN identifier, CAN FD flags) get lost in a generic byte-bus mapping and would have to be re-encoded at the application level.

Summary

AspectKey takeaway

ACF_GBB / ACF_ABB

A generic request/response transaction format for bus systems without their own ACF format

Header fields

byte_bus_id, evt, hs, cs, transaction_num, op, rsp, err, ms, read_size/segment_num — the semantics read like a classic request/response bus protocol

ABB vs. GBB

Same pattern as CAN_BRIEF vs. CAN — ABB drops the timestamp

Use case

A fallback for niche protocols without a dedicated ACF format — not a replacement for CAN/LIN/FlexRay/MOST where those exist

Status in AUTOSAR

Not specified (as of R24-11) — like all 2025 additions from Part 6

Back to the series overview: IEEE 1722 Part 1 — Fundamentals