Part 1 and Part 2 introduced AVTP and ACF conceptually. This part shows the ARXML side — with the actual container and parameter names from Chapter 10 of AUTOSAR_CP_SWS_IEEE1722TransportLayer.pdf (R24-11), not simplified placeholders.

The container hierarchy

IEEE1722Tp: container hierarchy
IEEE1722Tp
 ├── IEEE1722TpGeneral                       (0..1)
 │    ├── IEEE1722TpDevErrorDetect
 │    ├── IEEE1722TpVersionInfoApi
 │    ├── IEEE1722TpMainFunctionTx           (Period, PartitionRef)
 │    └── IEEE1722TpMainFunctionRx           (Period, PartitionRef)
 └── IEEE1722TpConfig                        (0..1)
      ├── IEEE1722TpLowerLayerPduPool        (1..*)
      │    ├── IEEE1722TpLowerLayerTxPduPoolEntry (0..*)
      │    │    ├── IEEE1722TpLowerLayerTxPduId
      │    │    └── IEEE1722TpLowerLayerTxPduRef   → Pdu
      │    └── IEEE1722TpLowerLayerRxPduPoolEntry (0..*)
      │         ├── IEEE1722TpLowerLayerRxPduId
      │         └── IEEE1722TpLowerLayerRxPduRef   → Pdu
      └── IEEE1722TpStream                   (1..*)
           ├── IEEE1722TpStreamIdUniquePart
           ├── IEEE1722TpStreamIdMacAddress   (0..1)
           ├── IEEE1722TpStreamIndex
           ├── IEEE1722TpStreamMaxTransitTime
           ├── IEEE1722TpStreamVersion
           ├── IEEE1722TpEthIfClkUnitRef
           ├── IEEE1722TpStbMSynchronizedTimeBaseRef
           ├── IEEE1722TpStreamLowerLayerPduPoolRef  → IEEE1722TpLowerLayerPduPool
           ├── IEEE1722TpStreamDirection      (Choice: Tx | Rx, each with TxQueue/RxQueue)
           └── IEEE1722TpStreamSubtype        (Choice, exactly 1)
                ├── IEEE1722TpStreamAAF
                ├── IEEE1722TpStreamCRF
                ├── IEEE1722TpStreamIIDC
                ├── IEEE1722TpStreamRVF
                └── IEEE1722TpStreamACF
                     ├── IEEE1722TpStreamAcfHeaderType (TIME_SYNCHRONOUS | NON_TIME_SYNCHRONOUS)
                     ├── IEEE1722TpAcfCollectionThreshold
                     ├── IEEE1722TpAcfCollectionTimeout
                     ├── IEEE1722TpStreamAcfMixedBusTypeCollection
                     └── IEEE1722TpStreamAcfPayload (Choice, 1..*)
                          ├── IEEE1722TpStreamAcfCan   → IEEE1722TpStreamAcfCanPdu (1..*)
                          └── IEEE1722TpStreamAcfLin

The module supports all three post-build variants (VARIANT-PRE-COMPILE, VARIANT-LINK-TIME, VARIANT-POST-BUILD) — most parameters are only finally settled at build time or even post-build time, not necessarily when first laying out the ARXML structure.

The key parameters of IEEE1722TpStream

ParameterMeaning

IEEE1722TpStreamIdUniquePart / IEEE1722TpStreamIdMacAddress

Together they form the stream ID per IEEE 1722 (MAC address + unique part) — IEEE1722TpStreamIdMacAddress is optional (0..1) if deriving it from the board’s MAC address is sufficient

IEEE1722TpStreamIndex

Handle index for API access in the communication stack — explicitly not the same as the actual stream ID from the two parameters above (see the warning below)

IEEE1722TpStreamMaxTransitTime

Maximum transit time of the stream, in seconds

IEEE1722TpStreamLowerLayerPduPoolRef

Reference to exactly one IEEE1722TpLowerLayerPduPool — this is how the stream is linked to a generic Pdu for Tx/Rx

IEEE1722TpEthIfClkUnitRef / IEEE1722TpStbMSynchronizedTimeBaseRef

References to the time source from which the avtp_timestamp for transmission is derived

The specification explicitly points out: IEEE1722TpStreamIndex "is NOT related to the stream id combined out of IEEE1722TpStreamIdUniquePart and IEEE1722TpStreamIdMacAddress." A common configuration mistake in practice is assuming the two values must match or can be derived from each other — they are fully independent identifiers with different purposes (API handle vs. wire-format ID).

Stream-to-switch-port mapping: indirect, not direct

An obvious assumption would be that an IEEE1722TpStream references a switch port directly (analogous to EthSwtPortIdx in the EthSwt ARXML configuration). That’s not the case:

Stream to switch port: no direct parameter in the IEEE1722Tp module

IEEE1722TpStreamLowerLayerPduPoolRef only references an IEEE1722TpLowerLayerPduPool, whose entries (Tx/RxPduPoolEntry) in turn only reference a generic Pdu — there is no EthSwtPortRef or similar directly in the IEEE1722Tp module. That Pdu gets forwarded by PduR, which hands it off to SoAd — not through some "PDU routing configuration" in EthIf or EthSwt, which doesn’t exist as such. Which physical switch port ends up serving the stream is a pure Layer 2 forwarding decision made by the switch chip (destination MAC address, possibly VLAN) — independent of the AUTOSAR PDU identity. IEEE1722Tp itself has no notion of switch ports, and neither do PduR/SoAd treat "switch port" as a configuration quantity at all.

For practical configuration work, this means: the stream-to-port question can’t be answered within the IEEE1722Tp ARXML at all. PduR routes the Pdu to SoAd, SoAd maps it to a socket connection (SoAdSocketConnection), which in turn is bound to EthIf/Eth — only on the finished Ethernet frame does the switch decide, based on the destination MAC address (and VLAN membership, if any), which port to forward it out of. That’s a configuration layer completely separate from the IEEE1722Tp ARXML.

Example configuration: an ACF_CAN transmit stream

Illustrative (container and parameter names are real, concrete values are made up) — a stream that transmits CAN messages via NTSCF:

<IEEE1722TP-STREAM>
  <SHORT-NAME>Stream_AcfCan_Tx_Zone1</SHORT-NAME>
  <IEEE1722TP-STREAM-ID-UNIQUE-PART>1</IEEE1722TP-STREAM-ID-UNIQUE-PART>
  <IEEE1722TP-STREAM-INDEX>0</IEEE1722TP-STREAM-INDEX>
  <IEEE1722TP-STREAM-MAX-TRANSIT-TIME>0.002</IEEE1722TP-STREAM-MAX-TRANSIT-TIME>
  <IEEE1722TP-STREAM-VERSION>0</IEEE1722TP-STREAM-VERSION>
  <IEEE1722TP-STREAM-LOWER-LAYER-PDU-POOL-REF DEST="IEEE1722TP-LOWER-LAYER-PDU-POOL">
    /IEEE1722Tp/IEEE1722TpConfig/PduPool_Zone1_Tx
  </IEEE1722TP-STREAM-LOWER-LAYER-PDU-POOL-REF>
  <IEEE1722TP-STREAM-DIRECTION>
    <IEEE1722TP-STREAM-TX/>
  </IEEE1722TP-STREAM-DIRECTION>
  <IEEE1722TP-STREAM-SUBTYPE>
    <IEEE1722TP-STREAM-ACF>
      <IEEE1722TP-STREAM-ACF-HEADER-TYPE>NON_TIME_SYNCHRONOUS</IEEE1722TP-STREAM-ACF-HEADER-TYPE>
      <IEEE1722TP-ACF-COLLECTION-THRESHOLD>256</IEEE1722TP-ACF-COLLECTION-THRESHOLD>
      <IEEE1722TP-ACF-COLLECTION-TIMEOUT>0.001</IEEE1722TP-ACF-COLLECTION-TIMEOUT>
      <IEEE1722TP-STREAM-ACF-MIXED-BUS-TYPE-COLLECTION>false</IEEE1722TP-STREAM-ACF-MIXED-BUS-TYPE-COLLECTION>
      <IEEE1722TP-STREAM-ACF-PAYLOAD>
        <IEEE1722TP-STREAM-ACF-CAN>
          <IEEE1722TP-STREAM-ACF-BUS-ID>1</IEEE1722TP-STREAM-ACF-BUS-ID>
          <IEEE1722TP-STREAM-ACF-CAN-MESSAGE-TYPE>CAN</IEEE1722TP-STREAM-ACF-CAN-MESSAGE-TYPE>
        </IEEE1722TP-STREAM-ACF-CAN>
      </IEEE1722TP-STREAM-ACF-PAYLOAD>
    </IEEE1722TP-STREAM-ACF>
  </IEEE1722TP-STREAM-SUBTYPE>
</IEEE1722TP-STREAM>

IEEE1722TpStreamAcfMixedBusTypeCollection = false in this example means: this stream only ever collects CAN messages — for a mixed CAN+LIN stream (see Part 2), the value would need to be set to true and an additional IEEE1722TpStreamAcfLin container configured.

Typical configuration mistakes

MistakeEffect

Confusing IEEE1722TpStreamIndex with the stream ID

API calls fail, or address the wrong stream, even though the wire-format ID is configured correctly

IEEE1722TpStreamLowerLayerPduPoolRef points to a pool without a matching Tx/RxPduPoolEntry for the chosen IEEE1722TpStreamDirection

The stream can’t be sent/received — the error often only shows up at runtime, not already during ARXML validation

IEEE1722TpEthIfClkUnitRef/IEEE1722TpStbMSynchronizedTimeBaseRef not consistent with the actually synchronized time-base module

avtp_timestamp is set but not in sync with the timestamps of other ECUs on the network — TSN determinism is lost without an obvious configuration error

Downstream configuration (PduR routing to SoAd, SoAdSocketConnection) not reconciled with the IEEE1722Tp side

The stream is generated correctly but delivered nowhere, or with the wrong destination MAC address — since IEEE1722Tp itself has no visibility into PduR/SoAd/switch ports, this only surfaces on review of the whole chain

Summary

AspectKey takeaway

Container hierarchy

IEEE1722Tp → IEEE1722TpGeneral/IEEE1722TpConfig → IEEE1722TpLowerLayerPduPool + IEEE1722TpStream (with a subtype choice)

Stream ID vs. stream index

Two independent identifiers — confusing them is a common pitfall the specification explicitly calls out

Switch-port mapping

No direct parameter in the IEEE1722Tp module itself: PduR routes the generic Pdu to SoAd, and the physical switch port only emerges as a pure Layer 2 forwarding decision based on the destination MAC address on the finished Ethernet frame

Next step

Part 4 shows end-to-end practical examples, followable with Open1722

Next in the series: IEEE 1722 Part 4 — End-to-End Practical Examples with Open1722