Teil 6 hat BYTE_BUS/GBB und BYTE_BUS_BRIEF/ABB als weitere, in AUTOSAR nicht enthaltene 2025er-Ergänzungen genannt. Anders als CAN_XL (Teil 7) oder CAN_V2 (Teil 8) tunneln GBB/ABB kein konkretes Feldbusprotokoll — sie sind ein generischer Rahmen für Bussysteme, die (noch) kein eigenes ACF-Format haben.

Wofür GBB/ABB gedacht sind

ACF_GBB (Generic Byte Bus, Kapitel 9.4.14) und ACF_ABB (Abbreviated Byte Bus, Kapitel 9.4.15) transportieren keine feldbus-spezifische Semantik wie ACF_CAN oder ACF_LIN — stattdessen bilden sie ein generisches Request/Response-Transaktionsmodell ab, das sich auf beliebige Byte-orientierte Busprotokolle abbilden lässt.

Die genaue Bedeutung einzelner Header-Bits (hs, cs, op, rsp, err) ist im frei zugänglichen Quellcode nur über die Feldnamen selbst erschließbar, nicht über eine ausführliche Beschreibung — der volle Text von Kapitel 9.4.14 des Standards ist kostenpflichtig. Die folgende Einordnung ist daher eine plausible, aber nicht letztgültig verifizierte Interpretation der Feldnamen.

Header-Felder im Überblick

ACF_GBB vs. ACF_ABB: derselbe Transaktions-Header
FeldBreiteVermutete Bedeutung (aus dem Feldnamen)

byte_bus_id

11 Bit

Identifiziert die Businstanz — dieselbe Breite wie bei CAN_V2/CAN_XL (siehe Teile 7 und 8)

message_timestamp

64 Bit (nur GBB)

Wie bei CAN/CRF — Zeitbezug der Transaktion

evt

4 Bit

Event-/Nachrichtentyp innerhalb der generischen Transaktion

hs

1 Bit

Handshake-Flag — vermutlich Bestätigung einer Bus-Transaktion auf Protokollebene (analog zu einem ACK-Bit)

cs

1 Bit

Chip-Select-Flag — deutet auf eine Zielrichtung Richtung SPI-artiger Busprotokolle mit physischer Chip-Select-Leitung hin

transaction_num

8 Bit

Korrelations-ID, um eine Response eindeutig ihrer Request zuzuordnen

op

1 Bit

Operation — vermutlich Lese- vs. Schreibzugriff

rsp

1 Bit

Kennzeichnet die Nachricht als Antwort (statt Anfrage)

err

1 Bit

Fehler-Flag für die Transaktion

ms

1 Bit

"More Segments" — wie bei CAN_XL (Teil 7): Fragmentierung für Transfers, die nicht in eine ACF-Nachricht passen

read_size/segment_num

12 Bit

Doppelt genutztes Feld — bei einer Leseanfrage die angeforderte Größe, bei einer (fragmentierten) Antwort die Segmentnummer

Das Zusammenspiel aus op/rsp/err/transaction_num liest sich wie ein klassisches Request/Response-Bus-Protokoll (anfragen, antworten, Fehler melden, Anfrage und Antwort per ID korrelieren) — ähnlich dem Muster, das man von SPI- oder I2C-Transaktionen mit Adress-/Datenzyklus kennt, nur protokollagnostisch gehalten.

ACF_ABB: dieselbe Struktur ohne Zeitstempel

ACF_ABB übernimmt exakt dieselben Transaktionsfelder wie ACF_GBB, verzichtet aber auf message_timestamp — dasselbe Muster wie bei CAN/CAN_BRIEF oder CAN_XL/CAN_XL_BRIEF. Für generische Bus-Transaktionen, bei denen kein Zeitbezug ausgewertet wird, spart das acht Byte pro Nachricht.

Warum das für automotive Nischenprotokolle relevant ist

Ein Zonal Controller trifft in der Praxis gelegentlich auf Bussysteme, für die es kein etabliertes ACF-Format gibt — sei es ein herstellerspezifisches Diagnoseprotokoll, ein Sensor mit proprietärem Registerzugriff, oder ein Legacy-Protokoll aus einem zugekauften Modul. GBB/ABB bieten für genau diesen Fall einen Ausweg, ohne auf ein eigenes, erst noch zu standardisierendes ACF-Format warten zu müssen.

GBB/ABB sind ein generischer Fallback, kein Ersatz für ein dediziertes Format. Wo ein spezifisches ACF-Format existiert (CAN, LIN, FlexRay, MOST, …​), sollte es verwendet werden — die feldbus-spezifische Semantik (z. B. CAN-Identifier, CAN-FD-Flags) geht bei einer generischen Byte-Bus-Abbildung verloren und müsste auf Anwendungsebene neu codiert werden.

Zusammenfassung

AspektKernaussage

ACF_GBB / ACF_ABB

Generisches Request/Response-Transaktionsformat für Bussysteme ohne eigenes ACF-Format

Header-Felder

byte_bus_id, evt, hs, cs, transaction_num, op, rsp, err, ms, read_size/segment_num — Semantik liest sich wie ein klassisches Request/Response-Busprotokoll

ABB vs. GBB

Gleiches Muster wie CAN_BRIEF vs. CAN — ABB verzichtet auf den Zeitstempel

Einsatzgebiet

Fallback für Nischenprotokolle ohne dediziertes ACF-Format — kein Ersatz für CAN/LIN/FlexRay/MOST, wo diese existieren

Status in AUTOSAR

Nicht spezifiziert (Stand R24-11) — wie alle 2025er-Ergänzungen aus Teil 6

Zurück zur Serienübersicht: IEEE 1722 Teil 1 — Grundlagen