struct ara::diag::GenericUDSService::OperationOutput

Die Struktur ara::diag::GenericUDSService::OperationOutput dient im Modul diag als Ausgabestruktur für die Nutzdaten positiver UDS-Antwortnachrichten [SWS_DM_00632]. Eine Anwendung befüllt nach erfolgreicher Ausführung eines generischen UDS-Dienstes die Byte-Variable responseData und übergibt die Instanz an das Diagnostic Management. Dabei darf der UDS Service-Identifier (SID) nicht in responseData enthalten sein, da dieser automatisch durch die Plattform ergänzt wird [SWS_DM_00632]. Für Fehlerszenarien und negative Antworten ist die Struktur nicht vorgesehen.

mehr ›

Kontext

Die Datenstruktur ara::diag::GenericUDSService::OperationOutput dient innerhalb der AUTOSAR Adaptive Platform im Modul diag als standardisierter Ausgabekanal für generische UDS-Dienste [SWS_DM_00632]. Sie ist in der Header-Datei #include "ara/diag/generic_uds_service.h" definiert und fungiert als Kapselung für die Nutzdaten einer erfolgreichen UDS-Dienstausführung [SWS_DM_00632]. Die wesentlichen Interaktionspartner sind die anwendungsspezifische Implementierung des generischen UDS-Service-Handlers sowie das übergeordnete Diagnostic Management der Plattform AUTOSAR_AP_SWS_Diagnostics S. 80. Während das Diagnostic Management die Koordination mit dem externen Diagnosetester, die Protokollvalidierung und das Rahmenwerk übernimmt, stellt OperationOutput die isolierte Nutzlast für die positive UDS-Antwortnachricht bereit [SWS_DM_00632].

Lebenszyklus

Instanzen von ara::diag::GenericUDSService::OperationOutput weisen einen stark fokussierten und kurzlebigen Lebenszyklus auf. Die Struktur wird durch die Dienstanwendung im lokalen Kontext einer eingehenden UDS-Anfrage instanziiert. Über die einzige öffentliche Elementvariable responseData vom Typ ara::core::Vector<std::uint8_t> übernimmt die Struktur den vollständigen Besitz der Nutzdatenbytes [SWS_DM_00632].

Interpretation: Die Lebensdauer von OperationOutput ist flüchtig und an die Dauer der jeweiligen Anfragebearbeitung gebunden; die Instanz dürfte nach ihrer Befüllung mittels Rückgabewert oder Verschiebesemantik an das Diagnostic Management übergeben und nach der Serialisierung in den UDS-Antwortframe wieder zerstört werden. Frage Q-c736182a9518978a (offen) Da es sich um ein reines Datenübertragungsobjekt (DTO) ohne interne Zustandslogik handelt, existieren keine Zustandsübergänge. Hinsichtlich der Nebenläufigkeit bietet OperationOutput keine inhärente Thread-Sicherheit; da die Instanziierung und Befüllung jedoch pro Anfrage isoliert innerhalb des Bearbeitungskontexts erfolgt, ist bei regulärer Dienstanwendung keine externe Synchronisation erforderlich.

Nutzungspfad

Der reguläre Ablauf bei der Verarbeitung einer Diagnoseanforderung gliedert sich in folgende Schritte:

• Empfang: Das Diagnostic Management empfängt eine UDS-Anfrage von einem externen Diagnosetester und leitet sie an die entsprechende Instanz von GenericUDSService weiter AUTOSAR_AP_SWS_Diagnostics S. 81.
• Dienstausführung: Die Anwendung interpretiert die empfangenen Parameter und führt die interne Diagnosefunktion aus.
• Ergebnisbereitstellung: Bei erfolgreicher Verarbeitung instanziiert die Anwendung ein Objekt vom Typ OperationOutput und weist dem Feld responseData die Nutzdaten der Antwort zu [SWS_DM_00632]. Hierbei schreibt die Spezifikation verbindlich vor, dass responseData ausschließlich die Datenbytes ohne den Service-Identifier (SID) enthalten darf [SWS_DM_00632].
• Übergabe: Die Anwendung übergibt OperationOutput an das Diagnostic Management. Interpretation: Die Übergabe erfolgt typischerweise als synchroner Rückgabewert oder eingebettet in einen asynchronen Zukunftswert wie ara::core::Future. Frage Q-2dcf40060cca29a1 (offen)
• Nachrichtenversand: Das Diagnostic Management stellt den positiven SID automatisch voran, komplettiert das UDS-Telegramm und übermittelt die Antwort an den Diagnosetester.

Sequenzdiagramm: Ablauf der UDS-Antwortgenerierung und Übergabe über OperationOutput. Quellen: [SWS_DM_00632], AUTOSAR_AP_SWS_Diagnostics S. 81

Fehlerszenarien

Bei der Verwendung der Struktur sind wesentliche Randbedingungen und Verhaltensmuster im Fehlerfall zu beachten:

• Ausschluss negativer Antworten: Gemäß Spezifikation repräsentiert OperationOutput explizit und ausschließlich den Inhalt positiver Antwortnachrichten [SWS_DM_00632]. Interpretation: Kann eine Dienstanforderung nicht erfolgreich bearbeitet werden (z. B. infolge unzulässiger Parameter oder ungültiger Vorbedingungen), dürfte kein OperationOutput erzeugt werden; stattdessen signalisiert die Anwendung einen Negative Response Code (NRC) an das Diagnostic Management. Frage Q-09abb9092c1dc167 (offen)
• Fehlerhafte SID-Inklusion: Wird der Service-Identifier irrtümlich in responseData eingefügt, entsteht ein fehlerhaft formatiertes UDS-Telegramm, da das Diagnostic Management den SID bei positiven Antworten eigenständig voranstellt [SWS_DM_00632].
• Speicherallokation: Da responseData als dynamischer Vektor (ara::core::Vector) deklariert ist, müssen bei der Zuweisung sehr großer Nutzdatenmengen mögliche Speicherengpässe berücksichtigt werden [SWS_DM_00632].