Automotive VAG filter fields

The VAG profile uses CAN fields on the Physical layer, ISO-TP / TP2.0 fields on the Transport layer, and UDS / KWP2000 fields on the Protocol layer. In a mixed trace, use or to select different protocols on the same layer with one expression.

Selecting a protocol

Both layers use protocol.type. Its values and suggestions depend on the selected layer. The field identifies the message's protocol, not the physical adapter.

Layer	Field	Type	Values
Transport	protocol.type	String	isotp, tp20
Protocol	protocol.type	String	uds, kwp2000

Example: ISO-TP messages on the Transport layer.

protocol.type == isotp

Example: KWP2000 messages on the Protocol layer.

protocol.type == kwp2000

Example: a protocol type and service.

protocol.type == uds and uds.service == 0x22

Example: several protocol types.

protocol.type in (uds, kwp2000)

Suggestions list protocols present in the trace. You can enter an absent type manually. See protocol type suggestions for how the list updates.

For diagnostics over CAN, TP2.0 belongs to the Transport layer and KWP2000 to the Protocol layer.

Shared diagnostic addressing

The address.* fields work at the Physical (CAN), Transport (ISO-TP), and Protocol (UDS) levels. Values come from the selected diagnostic profile, including the 11-bit or 29-bit CAN identifier format, independently of row labels and RX/TX. These fields are not published for TP2.0, KWP2000, or CANopen; their records in a mixed source have no diagnostic address values.

Field	Type	Meaning
address.type	String	physical, functional, unknown
address.role	String	physicalRequest, physicalResponse, functionalRequest, unknown
address.group	String	Functional group identifier; absent for physical channels
address.requestId	Integer	Physical request CAN ID or functional group CAN ID
address.responseId	Integer	Physical response CAN ID; absent for functional groups

unknown means addressing could not be determined because information is missing or conflicting. In this case, channel identifiers and the group identifier are absent. At the UDS level, the decoded message is also checked against the address role, so a conflict may only become visible after decoding.

Functional requests, including passively received requests:

address.type == functional

Both sides of one physical channel:

address.type == physical and address.requestId == 0x714 and address.responseId == 0x77E

Requests to the VAG coordination group:

address.group == "vag.coordination"

Unknown and conflicting addresses:

address.type == unknown

A group filter selects requests to that group, not replies from assumed members. Replies remain physical, and group membership is not inferred automatically. The example IDs 0x714/0x77E are a specific pair, not a universal VAG rule. The old uds.addressing field was removed: replace it with address.type in saved expressions.

UDS — Protocol

Field	Type	Meaning and applicability
uds.service	Integer	Normalized original service, shared by a recognized request, positive response and negative response
uds.rawSid	Integer	Actual SID byte in the message
uds.request	Boolean	The message has a known request role
uds.response	Boolean	The message has a known response role
uds.positiveResponse	Boolean	Positive response; response-type fields do not apply to requests
uds.negativeResponse	Boolean	Negative response; response-type fields do not apply to requests
uds.negativeResponseCode	Integer	Negative response code (NRC)
uds.did	Integer	DID in recognized read/write-by-identifier requests and positive responses
uds.rid	Integer	RID in a recognized RoutineControl request or positive response
uds.session	Integer	Session from DiagnosticSessionControl or its positive response; not the current session of every message
uds.src	Integer	Source address from the diagnostic context, when known
uds.dst	Integer	Destination address from the diagnostic context, when known
uds.data	Bytes	Complete UDS application message including SID, without ISO-TP overhead

uds.src and uds.dst come from the diagnostic context. Do not substitute them for CAN IDs without checking the message's addressing. Use can.id on the Physical layer or isotp.canId on the Transport layer for CAN IDs.

Service and SID

uds.service == 0x22

This matches recognized 22 … requests, 62 … positive responses and 7F 22 … negative responses. To select the positive SID specifically:

uds.rawSid == 0x62

VIN by DID:

uds.service == 0x22 and uds.did == 0xF190

A negative response does not contain the original request's DID or RID. Filtering by those fields does not add that response automatically. To include negative responses to the read service, broaden the filter expression:

uds.service == 0x22 and (uds.did == 0xF190 or uds.negativeResponse == true)

A negative response in this selection may belong to another DID of the same service. Check the sequence and addressing to establish the relationship.

Waiting for processing to complete:

uds.negativeResponseCode == 0x78

0x78 means ResponsePending, not a final rejection. This filter finds the pending response but hides a subsequent positive response. Return to the service filter to examine completion.

KWP2000 — Protocol

This section covers KWP2000 over TP2.0 on CAN; K-Line capture is outside its scope.

Field	Type	Meaning and applicability
kwp.service	Integer	Normalized original service
kwp.rawSid	Integer	Actual message SID
kwp.request	Boolean	Known request role
kwp.response	Boolean	Known response role
kwp.positiveResponse	Boolean	Positive response; not applicable to requests
kwp.negativeResponse	Boolean	Negative response; not applicable to requests
kwp.negativeResponseCode	Integer	Negative response code (NRC)
kwp.localId	Integer	Local data or routine identifier, when extracted from the message
kwp.commonId	Integer	Common data identifier, when present and recognized
kwp.src	Integer	Known logical source address
kwp.dst	Integer	Known logical destination address
kwp.data	Bytes	Complete KWP2000 application message including SID

Read-by-local-identifier service:

kwp.service == 0x21

Negative responses from both protocols in one application-layer table:

uds.negativeResponse == true or kwp.negativeResponse == true

Do not replace or with and: one message cannot belong to both UDS and KWP2000.

The separate TesterPresent toggle hides the corresponding recognized UDS/KWP2000 messages and works together with the expression. Enable their display before investigating TesterPresent itself.

ISO-TP — Transport

Field	Type	Meaning and applicability
isotp.canId	Integer	CAN identifier of the transport message
isotp.frameType	String	Type from which the row was formed: single, first, consecutive, flowControl
isotp.payloadLength	Integer	ISO-TP payload length without PCI
isotp.flowStatus	String	Flow Control only: continue, wait, overflow
isotp.blockSize	Integer	Block size from Flow Control
isotp.stMin	Integer	Raw STmin byte from Flow Control; not a universal millisecond count
isotp.fd	Boolean	Consistent CAN FD flag across source frames; absent if evidence is insufficient or contradictory
isotp.brs	Boolean	Consistent BRS flag across source frames; absent if evidence is insufficient or contradictory
isotp.data	Bytes	ISO-TP payload without PCI

Rows on the Transport layer result from processing source frames. Their count and payload need not match the number or contents of individual CAN frames. Switch to the Physical layer to inspect specific PCI bytes.

Receiver waiting or overflowing:

isotp.frameType == flowControl and isotp.flowStatus in (wait, overflow)

All Flow Control messages for a selected CAN ID:

isotp.canId == 0x7E8 and isotp.frameType == flowControl

0x7E8 is an example, not a universal VAG address. Use the identifier from your trace.

TP2.0 — Transport

Field	Type	Meaning and applicability
tp20.channel	Integer	Observed channel number; may be absent before channel establishment
tp20.frameType	String	Channel setup or operation message type; values listed below
tp20.sequence	Integer	Data or acknowledgment sequence number
tp20.ack	Boolean	Acknowledgment requested by a data message; does not mean this row is an acknowledgment
tp20.rnr	Boolean	Receiver Not Ready in an acknowledgment message
tp20.applicationType	Integer	Application type from setup or known channel state
tp20.data	Bytes	Reassembled TP2.0 application data, when available

Values of tp20.frameType:

Group	Values
Broadcast exchange	broadcastRequest, broadcastResponse
Channel establishment	channelSetup, channelAcknowledge
Establishment failure	channelApplicationTypeNotSupported, channelApplicationTypeTemporarilyNotSupported, channelNoResources
Data and acknowledgments	data, acknowledge
Connection parameters	connectionSetup, connectionAcknowledge
Control and termination	connectionTest, break, disconnect

Receiver not ready:

tp20.rnr == true

Opening and closing a channel:

tp20.frameType in (channelSetup, channelAcknowledge, disconnect)

Acknowledgments:

tp20.frameType == acknowledge

Channel establishment failure:

tp20.frameType in (channelApplicationTypeNotSupported, channelApplicationTypeTemporarilyNotSupported, channelNoResources)

Decoding a dynamic channel requires its setup context; see VAG Tracer layers.

For more on matching messages, see services and ECU responses.