Functional vs. Physical Addressing
Physical addressing sends a UDS request to one ECU, functional addressing to all of them. CAN IDs 0x7E0 and 0x7DF, the single-frame rule and the response rules.
Updated This page as Markdown
In short
In UDS diagnostics, physical addressing sends a request to exactly one ECU (1:1), functional addressing sends it to a group or all ECUs at once (1:n). On 11-bit CAN the classic example is 0x7E0 (physical, engine ECU) versus 0x7DF (functional, all OBD ECUs). ISO 15765-2 allows functional requests only as single frames, and ISO 14229-1 suppresses several negative responses to them. ECUs that behave differently on the two paths are a regular source of findings.
What is functional vs. physical addressing?
Physical addressing means a request goes to one specific ECU, which answers it. Functional addressing means a request goes to a group of ECUs, possibly all of them, and every ECU that supports it answers. In ISO 15765-2 this is the target address type (TAtype) of a message.
On 11-bit CAN with the OBD-style addressing many vehicles follow, a tester sends physically to the engine ECU on 0x7E0 and gets the answer on 0x7E8, and sends functionally on 0x7DF, where every OBD-relevant ECU listens. Manufacturer-specific diagnostics use their own ID pairs, but the principle is the same. On DoIP, the tester sends to a logical address; ISO 13400-2 reserves address ranges for functional addressing next to the physical addresses of each ECU.
Where is it defined?
ISO 15765-2 defines physical and functional addressing for ISO-TP on CAN and restricts functional messages to single frames, because flow control from many receivers at once would collide. ISO 14229-1 defines how a server responds: for functionally addressed requests it does not send the negative responses serviceNotSupported (0x11), subFunctionNotSupported (0x12), requestOutOfRange (0x31) and the two “not supported in active session” codes (0x7E, 0x7F). ISO 13400-2 defines logical addressing for DoIP.
What it means in practice
Typical functional requests are TesterPresent (3E 80 on 0x7DF), DiagnosticSessionControl to put all ECUs into extended session, CommunicationControl and ControlDTCSetting before flashing. All of them change the state of many ECUs at once, which is exactly why the access rules matter.
The bench findings come from inconsistency. We see ECUs that reject a service physically with 7F 28 22 but accept it functionally, ECUs that enter a session on a functional request without the checks they apply physically, and gateways that forward functional requests into domains where physical requests are blocked. Suppressed negative responses also hide information: silence on a functional request does not mean the ECU ignored it.
How AutoST tests it
AutoST’s enumeration discovers the physical ISO-TP endpoints of an ECU across the 11-bit and 29-bit ranges and then runs session, service and DID enumeration against each pair, so every result is tied to one ECU and one address. Over DoIP the same enumeration runs against each logical address the gateway routes to.
Common misunderstandings
Functional addressing is not “broadcast without consequences”. A functional DiagnosticSessionControl or CommunicationControl hits every ECU that supports it, and a test that sends one on a vehicle network affects more than the device under test.
FAQ
Frequently asked questions
Why can a functional request only be a single frame?
A multi-frame ISO-TP transfer needs flow control from the receiver. If several ECUs received a functional first frame, they would all answer with flow control frames at once. ISO 15765-2 therefore limits functional addressing to single frames, at most 7 data bytes on classic CAN.
Do all ECUs answer a functional request?
No. An ECU that does not support the service or sub-function stays silent instead of sending serviceNotSupported, subFunctionNotSupported or requestOutOfRange, so the tester only hears from the ECUs that can act on it.
What is 0x18DB33F1?
The 29-bit functional request ID used for OBD on CAN with extended identifiers: target 0x33 (all OBD ECUs), source 0xF1 (the tester). Physical 29-bit requests use 0x18DA, then target and source address.
Sources
- ISO 15765-2:2024 Road vehicles, Diagnostic communication over CAN (DoCAN), Part 2: Transport protocol and network layer services (addressing, TAtype)
- ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer (response behaviour to functional requests)
- ISO 13400-2:2019 Road vehicles, Diagnostic communication over Internet Protocol (DoIP), Part 2: Transport protocol and network layer services
Related pages
- GlossaryISO-TP (ISO 15765-2)ISO-TP (ISO 15765-2) splits UDS messages into CAN frames: single, first, consecutive and flow-control frames. How it works and why malformed frames crash ECUs.
- GlossaryUDS (Unified Diagnostic Services)UDS (ISO 14229) is the diagnostic protocol of most automotive ECUs: sessions, services, DIDs and SecurityAccess. What it defines and why it is the first attack surface.
- GlossaryGateway ECU (Central Gateway)The gateway ECU connects the vehicle networks and decides which messages cross between them. Why it is the key security boundary and how its diagnostic routing fails.
- GlossaryTesterPresent (0x3E)UDS TesterPresent (0x3E) keeps a non-default session alive. Request and response bytes, the suppress bit, the S3 server timer, and the session bugs it exposes.
- PlatformKnow every door into the ECU.AutoST enumerates an ECU over UDS: diagnostic endpoints, sessions, all 255 services and readable DIDs, plus XCP/CCP discovery. Risky services are flagged automatically.
- Free toolsISO-TP Frame CalculatorHow many CAN frames does a UDS message need? Enter the payload length, pick classic CAN or CAN FD and flow control: first, consecutive and flow-control frames and timing.
