Funktionale vs. physische Adressierung

Was ist funktionale vs. physische Adressierung?

Physische Adressierung heißt: Ein Request geht an ein bestimmtes Steuergerät, und dieses antwortet. Funktionale Adressierung heißt: Ein Request geht an eine Gruppe von Steuergeräten, unter Umständen an alle, und jedes, das ihn unterstützt, antwortet. In ISO 15765-2 ist das der Target Address Type (TAtype) einer Nachricht.

Auf 11-Bit-CAN mit der OBD-artigen Adressierung, der viele Fahrzeuge folgen, sendet ein Tester physisch an das Motorsteuergerät auf 0x7E0 und bekommt die Antwort auf 0x7E8, und funktional auf 0x7DF, wo jedes OBD-relevante Steuergerät mithört. Herstellerspezifische Diagnose nutzt eigene ID-Paare, das Prinzip bleibt gleich. Bei DoIP sendet der Tester an eine logische Adresse; ISO 13400-2 reserviert neben den physischen Adressen der Steuergeräte eigene Bereiche für funktionale Adressierung.

Wo ist es definiert?

ISO 15765-2 definiert physische und funktionale Adressierung für ISO-TP auf CAN und beschränkt funktionale Nachrichten auf Single Frames, weil Flow Control von vielen Empfängern gleichzeitig kollidieren würde. ISO 14229-1 legt fest, wie ein Server antwortet: Auf funktional adressierte Requests sendet er die negativen Antworten serviceNotSupported (0x11), subFunctionNotSupported (0x12), requestOutOfRange (0x31) und die beiden “not supported in active session”-Codes (0x7E, 0x7F) nicht. ISO 13400-2 definiert die logische Adressierung für DoIP.

Was es in der Praxis bedeutet

Typische funktionale Requests sind TesterPresent (3E 80 auf 0x7DF), DiagnosticSessionControl, um alle Steuergeräte in die Extended Session zu bringen, sowie CommunicationControl und ControlDTCSetting vor dem Flashen. Alle ändern den Zustand vieler Steuergeräte auf einmal, und genau deshalb zählen die Zugriffsregeln.

Die Findings am Prüfstand entstehen aus Inkonsistenz. Wir sehen Steuergeräte, die einen Service physisch mit 7F 28 22 ablehnen, ihn funktional aber annehmen, Steuergeräte, die auf einen funktionalen Request ohne die Prüfungen in eine Session wechseln, die sie physisch anwenden, und Gateways, die funktionale Requests in Domänen weiterleiten, in denen physische Requests gesperrt sind. Unterdrückte negative Antworten verbergen außerdem Information: Stille auf einen funktionalen Request heißt nicht, dass das Steuergerät ihn ignoriert hat.

Wie AutoST es testet

Die Enumeration von AutoST findet die physischen ISO-TP-Endpunkte eines Steuergeräts im 11-Bit- und 29-Bit-Bereich und führt dann Session-, Service- und DID-Enumeration gegen jedes Paar aus, sodass jedes Ergebnis an ein Steuergerät und eine Adresse gebunden ist. Über DoIP läuft dieselbe Enumeration gegen jede logische Adresse, an die das Gateway routet.

Häufige Missverständnisse

Funktionale Adressierung ist kein “Broadcast ohne Folgen”. Ein funktionales DiagnosticSessionControl oder CommunicationControl trifft jedes Steuergerät, das es unterstützt, und ein Test, der so etwas in ein Fahrzeugnetz schickt, betrifft mehr als das Testobjekt.