struct ara::diag::CommunicationControl::ComCtrlRequestParamsType

Die Datenstruktur bündelt sämtliche Eingangsparameter einer UDS-Serviceanforderung 0x28 für die adaptive Kommunikationssteuerung gemäß [SWS_DM_00805]. Bei Eingang einer solchen Diagnosebotschaft deserialisiert die Plattform die Steuerungs- und Kommunikationstypen sowie die Knotenkennung und übergibt die befüllte Struktur an den entsprechenden Service-Handler. Die Anwendungssoftware wertet die enthaltenen Werte aus, um das Sende- und Empfangsverhalten definierter Netzwerksegmente gezielt zu beeinflussen (AUTOSAR_AP_SWS_Diagnostics §8.7.2 „Struct: ComCtrlRequestParamsType“). Als zustandsloser Datencontainer besitzt die Struktur keine eigene Concurrency-Synchronisation, weshalb Zugriffe im Ausführungskontext des Handlers verbleiben sollten.

mehr ›

Kontext

Die Struktur ara::diag::CommunicationControl::ComCtrlRequestParamsType ist ein zentraler Datentransfertyp innerhalb der funktionalen Diagnose-Schnittstelle von AUTOSAR Adaptive [SWS_DM_00805]. Sie ist in der Header-Datei ara/diag/communication_control.h deklariert und dient als standardisierter Parametercontainer, welcher alle Eingabeparameter einer Diagnoseanforderung des UDS-Dienstes 0x28 (CommunicationControl) kapselt (AUTOSAR_AP_SWS_Diagnostics §8.7.2 „Struct: ComCtrlRequestParamsType“).

Im Gesamtsystem agiert die Struktur als Vermittler zwischen dem AUTOSAR-Diagnosemanagement (Diagnostic Management) und der adaptiven Anwendungssoftware, welche für die fahrzeugspezifische Kommunikationssteuerung zuständig ist. Eingehende Diagnosebefehle von externen Testern werden auf Plattformebene deserialisiert und über diese Struktur an die Anwendung übergeben. Die Struktur umfasst drei öffentliche Membervariablen (AUTOSAR_AP_SWS_Diagnostics §8.7.2.1 „Public Member Variables“):

• controlType ([SWS_DM_01562], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.2 „controlType“): Definiert als std::uint8_t, transportiert dieses Feld die aus der UDS-Anfrage extrahierte Subfunktion zur Spezifikation des auszuführenden Steuerungsvorgangs.
• communicationType ([SWS_DM_01563], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.1 „communicationType“): Ebenfalls vom Typ std::uint8_t, repräsentiert dieses Feld den in der UDS-Anforderung angegebenen Kommunikationstyp (wie z. B. Normal- oder Netzwerkmanagement-Kommunikation).
• nodeIdentificationNumber ([SWS_DM_01564], AUTOSAR_AP_SWS_Diagnostics §8.7.2.1.3 „nodeIdentificationNumber“): Definiert als std::uint16_t, identifiziert diese Variable den konkreten Zielknoten bzw. das Teilnetzwerk, an das die Steueranweisung gerichtet ist.

Lebenszyklus

Als elementare C++-Struktur (struct) [SWS_DM_00805] weist ComCtrlRequestParamsType die Charakteristik eines einfachen Wertetyps (Plain Old Data / POD) auf. Sie besitzt keine interne Zustandsmaschine, keine virtuellen Funktionszeiger und keine dynamisch allokierten Speicherbereiche (AUTOSAR_AP_SWS_Diagnostics §8.7.2.1 „Public Member Variables“).

Die Erzeugung einer Instanz erfolgt typischerweise flüchtig durch das Diagnostic-Management-Framework: Sobald eine UDS-0x28-Nachricht empfangen und formal validiert wurde, instantiiert der Stack die Struktur und initialisiert die Membervariablen mit den decodierten Nutzdaten (Interpretation: Die Objekterzeugung obliegt vollständig der Middleware im Rahmen der Anforderungsannahme). Frage Q-1abe8049ce5759f2 (offen) Die Besitzverhältnisse sind streng auf den Kontext des Methodenaufrufs begrenzt. Die Plattform übergibt die Instanz üblicherweise per Wert oder konstanter Referenz an den Service-Handler der Applikation; die empfangende Anwendung übernimmt keinen dauerhaften Besitz der Instanz.

Entsprechend existieren keine Lebenszyklusphasen oder komplexen Statuswechsel. Die Zerstörung der Instanz erfolgt automatisch mit dem Verlassen des Gültigkeitsbereichs des jeweiligen Callback-Aufrufs. Im Hinblick auf Nebenläufigkeit implementiert ComCtrlRequestParamsType keine eigenen Synchronisationsmechanismen. Da die Member nach der Initialisierung durch die Plattform von der Anwendungssoftware im Regelfall rein lesend ausgewertet werden, dürfte der Zugriff thread-sicher sein, sofern die Instanz thread-lokal an den Bearbeitungskontext übergeben wird (Interpretation: Für die Auswertung sind keine externen Sperren erforderlich). Frage Q-d654753d06273bca (offen)

Nutzungspfad

Der typische Nutzungspfad im Rahmen der Diagnoseverarbeitung vollzieht sich in einer festen Schrittfolge von der Netzwerknachricht bis zur Applikationsreaktion (AUTOSAR_AP_SWS_Diagnostics §8.7.2 „Struct: ComCtrlRequestParamsType“):

1. Empfang der Diagnosebotschaft: Ein externer Diagnosetester sendet eine UDS-0x28-Anfrage an das Steuergerät. Das Adaptive Diagnostic Management nimmt das Datenpaket auf Transportebene entgegen.
2. Deserialisierung und Instanziierung: Der Diagnose-Stack parst die Nutzlast, erzeugt eine Instanz von ComCtrlRequestParamsType [SWS_DM_00805] und weist den Feldern controlType [SWS_DM_01562], communicationType [SWS_DM_01563] sowie nodeIdentificationNumber [SWS_DM_01564] die übertragenen Werte zu.
3. Übergabe an den Service-Handler: Die Middleware leitet die Instanz an die implementierte Callback-Methode der CommunicationControl-Schnittstelle in der adaptiven Applikation weiter.
4. Parameterauswertung und Ausführung: Die adaptive Applikation liest die Struktur aus. Anhand der nodeIdentificationNumber [SWS_DM_01564] wird ermittelt, ob der eigene Knoten oder ein Teilnetzwerk adressiert ist. Anschließend werden über controlType [SWS_DM_01562] und communicationType [SWS_DM_01563] die entsprechenden Sende- und Empfangsmodi aktiviert oder deaktiviert.
5. Rückmeldung: Nach erfolgter Ausführung bestätigt die Anwendung den Vorgang an das Diagnostic Management, welches die standardkonforme positive UDS-Antwort an den Diagnosetester übermittelt.

Sequenzdiagramm: Typischer Ablauf der Anfrageverarbeitung von der UDS-0x28-Botschaft bis zur Parameterauswertung in der Applikation. Quellen: [SWS_DM_00805], AUTOSAR_AP_SWS_Diagnostics §8.7.2 „Struct: ComCtrlRequestParamsType“