namespace apext::diag::uds_transport

Der Namespace apext::diag::uds_transport stellt die C++-Transportschnittstelle zur Entkopplung des generischen Diagnose-Managements von spezifischen UDS-Transportprotokollen bereit AUTOSAR_AP_SWS_Diagnostics §7.1 „UDS Transport Layer“. Protokoll-Plugins leiten sich von der Basisklasse UdsTransportProtocolHandler ab und durchlaufen einen strikten Lebenszyklus aus Konstruktion, Initialisierung, Start und geordnetem Stoppen [SWS_DM_00329]. Eingehende Nachrichten werden über IndicateMessage gemeldet und erhalten bei freien Kapazitäten einen speicherverwalteten UdsMessagePtr zur Nutzdatenübernahme. Eine zentrale Randbedingung ist, dass nach dem Stoppen keine weiteren Aufrufe an das Diagnose-Management außer der Bestätigungsmeldung erfolgen dürfen.

mehr ›

Kontext

Der Namespace apext::diag::uds_transport definiert die standardisierte C++-Transportschnittstelle (Transport Protocol API) für das Diagnose-Management (DM) in der AUTOSAR Adaptive Platform AUTOSAR_AP_SWS_Diagnostics §7.1 „UDS Transport Layer“. Die Architektur trennt den generischen Kern des Diagnose-Managements funktional von konkreten Netzwerk- und Transportschichten ab. Auf diese Weise können standardisierte Protokolle wie DoIP sowie künftige oder herstellerspezifische Transportprotokolle (beispielsweise für CAN, CAN-FD oder FlexRay) als modulare Plugins integriert werden AUTOSAR_AP_SWS_Diagnostics §7.1 „UDS Transport Layer“.

Die zentrale Vermittlungsinstanz bildet die Klasse UdsTransportProtocolMgr, welche die Interaktion zwischen den Instanzen des Diagnostic Server und den angebundenen Transportprotokollen koordiniert. Konkrete Protokoll-Plugins leiten sich von der abstrakten Basisklasse UdsTransportProtocolHandler ab AUTOSAR_AP_SWS_Diagnostics §7.1.1 „Support of UDS Transport Layer“ [SWS_DM_00315]. Einzelne Handler-Instanzen werden über UdsTransportProtocolHandlerID adressiert [SWS_DM_00336], während Kommunikationskanäle über den Typ ChannelID identifiziert werden [SWS_DM_00337]. Zur Unterstützung periodischer Datenabfragen nach ISO-Dienst 0x2A bindet die Schnittstelle zusätzlich die Klasse UdsTransportProtocolPeriodicHandler ein.

Lebenszyklus

Das Diagnose-Management steuert den Lebenszyklus jeder UdsTransportProtocolHandler-Instanz in einer fest vorgegebenen Reihenfolge [SWS_DM_00329]:

1. Erzeugung: Das DM instanziiert das Protokoll-Plugin über den Konstruktor UdsTransportProtocolHandler::UdsTransportProtocolHandler [SWS_DM_00329].
2. Initialisierung: Das DM ruft UdsTransportProtocolHandler::Initialize auf [SWS_DM_00329]. Bis auf die Abfrage von GetPeriodicHandler darf das DM vor der erfolgreichen Rückgabe von kInitializeOk keine weiteren Methoden auf dem Handler aufrufen [SWS_DM_01746].
3. Start und Betrieb: Nach erfolgreicher Initialisierung wird der Handler mit UdsTransportProtocolHandler::Start aktiviert. Erst nach diesem Aufruf verarbeitet das DM Meldungen über reaktivierte Kanäle via UdsTransportProtocolMgr::ChannelReestablished [SWS_DM_01744].
4. Terminierung: Wechselt das DM in den Zustand ApplicationState.kTerminating, ruft es für alle aktiven Plugins UdsTransportProtocolHandler::Stop auf [SWS_DM_00333]. Nach Rückkehr dieses Aufrufs darf das Plugin ausschließlich UdsTransportProtocolMgr::HandlerStopped aufrufen [SWS_DM_01741]. Das DM wartet aktiv auf diese Bestätigung [SWS_DM_00340].

Zustandsdiagramm: Lebenszyklusphasen und Übergangsbedingungen einer Transportprotokoll-Handler-Implementierung. Quellen: [SWS_DM_00329], [SWS_DM_00333], [SWS_DM_00340], [SWS_DM_01741], [SWS_DM_01744], [SWS_DM_01745], [SWS_DM_01746]

Nutzungspfad

Im laufenden Betrieb erfolgt die Weiterleitung eingehender Diagnosenachrichten über ein abgestimmtes Zusammenspiel von Handler und Manager:

1. Nachrichtenindikation: Empfängt der Handler Daten auf einem Kanal (ChannelID [SWS_DM_00337]), ruft er UdsTransportProtocolMgr::IndicateMessage auf. Dabei kann er Vorab-Nutzdaten in payloadInfo übergeben; empfohlen werden mindestens die ersten zwei Bytes zur frühzeitigen Erkennung funktionaler Anfragen AUTOSAR_AP_SWS_Diagnostics §7.1 „UDS Transport Layer“.
2. Pufferallokation: Ist das DM aufnahmebereit, antwortet IndicateMessage mit einem std::pair aus IndicationResult::kIndicationOk und einem gültigen Smart-Pointer UdsMessagePtr [SWS_DM_00309] [SWS_DM_00385]. Das referenzierte UdsMessage-Objekt besitzt eine Mindestkapazität von einem Byte [SWS_DM_00385]. Der Puffer wird als std::unique_ptr mit einem spezifischen Deleter des DM-Kerns verwaltet und ist nicht threadsicher [SWS_DM_00303]. Für Lesezugriffe existiert das konstante Äquivalent UdsMessageConstPtr [SWS_DM_00304].
3. Datenübergabe: Der Handler schreibt die empfangenen Diagnosedaten in den bereitgestellten Puffer, dessen Bytefolge über den Typ ByteSpan (Alias für ara::core::Span<ara::core::Byte> [SWS_DM_00338]) typisiert ist. Vermutlich dient die Bereitstellung der separaten Klasse UdsTransportProtocolPeriodicHandler über GetPeriodicHandler der Entkoppelung des periodischen Übertragungsdienstes 0x2A vom regulären UDS-Nachrichtenpfad. Frage Q-230ef0b7c384c594 (offen)

Sequenzdiagramm: Ablauf der Nachrichtenindikation und Pufferallokation zwischen Handler, Manager und DM-Kern. Quellen: AUTOSAR_AP_SWS_Diagnostics §7.1 „UDS Transport Layer“, [SWS_DM_00303], [SWS_DM_00309], [SWS_DM_00385], [SWS_DM_00386]

Fehlerszenarien

Die Spezifikation definiert konkrete Fehlerzustände und Vorbedingungen für die Transportanbindung:

• Fehlgeschlagene Initialisierung: Liefert UdsTransportProtocolHandler::Initialize das Ergebnis kInitializeFailed, bricht das DM den Initialisierungsprozess für diesen Handler sofort ab und ruft keine weiteren Methoden an ihm auf [SWS_DM_01745].
• Abweisung bei belegtem Diagnosekern: Wenn das DM durch eine laufende Servicebearbeitung derselben Tester-Present-Konversation blockiert ist und es sich nicht um ein funktionales Tester-Present mit payloadInfo 0x3E 0x80 handelt, liefert IndicateMessage das Ergebnis kIndicationOccupied zusammen mit einem nullptr anstelle eines Nachrichtenpuffers zurück [SWS_DM_00386].
• Unerlaubte Aufrufe nach Terminierung: Ruft ein Plugin nach Rückkehr von Stop eine andere Methode von UdsTransportProtocolMgr als HandlerStopped auf, verletzt dies die Protokollvorgaben [SWS_DM_01741]. Ebenso ignoriert das DM Signale wie ChannelReestablished, wenn sie vor dem erfolgreichen Aufruf von Start eingehen [SWS_DM_01744].