class ara::diag::DoIPGroupIdentification

Die Klasse ara::diag::DoIPGroupIdentification dient als abstrakte Schnittstelle für Adaptive-Anwendungen, um dem Diagnostic Management den aktuellen Status der DoIP-Gruppenidentifikation bereitzustellen [SWS_DM_00724]. Nach der portspezifischen Instanziierung aktiviert die Anwendung die Weiterleitung von Anfragen über Offer() und beendet diese vor der Objektzerstörung mittels StopOffer() [SWS_DM_00725]. Die Handler-Instanz ist unikat, weder kopier- noch verschiebbar und beantwortet Abfragen asynchron über ein ara::core::Future.

mehr ›

Kontext

Die Klasse ara::diag::DoIPGroupIdentification stellt die funktionale Schnittstelle des Diagnose-Managements (AUTOSAR AP SWS Diagnostics S. 73) zur Verfügung, über welche eine adaptive Anwendung den aktuellen Gruppenidentifikations-Status (GID-Status) für das DoIP-Protokoll bereitstellt [SWS_DM_00724]. Innerhalb der Plattformarchitektur agiert die Klasse als Vermittler zwischen zwei primären Interaktionspartnern: dem internen Diagnostic Management Daemon (DM), der standardisierte Fahrzeugidentifikations- und DoIP-Nachrichten über das Netzwerk abwickelt, und der anwendungsspezifischen Implementierung, welche die reine virtuelle Methode GetGidStatus() konkretisiert. Die Bereitstellung und das Entgegennehmen von Anfragen wird über explizite Dienstangebote gesteuert [SWS_DM_00725].

Lebenszyklus

Eine Instanz von DoIPGroupIdentification repräsentiert einen eindeutigen Diagnose-Port. Aus diesem Grund ist die Klasse als unikat verwaltetes Objekt ausgelegt: Sowohl Kopierkonstruktor [SWS_DM_01641] und Move-Konstruktor [SWS_DM_01642] als auch die entsprechenden Zuweisungsoperatoren [SWS_DM_01639], [SWS_DM_01640] sind explizit gelöscht (=delete).

Die Erzeugung erfolgt zwingend über den parametrisierten Konstruktor unter Angabe eines ara::core::InstanceSpecifier sowie des Nebenläufigkeitsmodus ConcurrencyType [SWS_DM_00722]. Der Lebenszyklus gliedert sich in folgende Phasen:

• Nicht angeboten (Not Offered): Nach der Konstruktion existiert das Objekt im Adressraum des Prozesses, empfängt jedoch noch keine Anfragen vom DM.
• Angeboten (Offered): Durch den synchronen Aufruf von Offer() [SWS_DM_00725] wird der Handler beim DM aktiviert, sodass eingehende DoIP-Statusanfragen weitergeleitet werden.
• Gestoppt (Stopped): Der Aufruf von StopOffer() [SWS_DM_00726] entzieht dem DM die Weiterleitungsberechtigung und überführt das Objekt zurück in den inaktiven Zustand.

Die Zerstörung erfolgt über den virtuellen Destruktor ~DoIPGroupIdentification() [SWS_DM_00723]. Hinsichtlich der Nebenläufigkeit ist der Konstruktor threadsicher, während Offer(), StopOffer() sowie der Destruktor nicht threadsicher sind [SWS_DM_00722], [SWS_DM_00723], [SWS_DM_00725], [SWS_DM_00726]. Die Threadsicherheit der Abfragefunktion GetGidStatus() wird bedingt durch den im Konstruktor gewählten ConcurrencyType definiert [SWS_DM_00724]. Interpretation: Der Destruktor dürfte laufende Weiterleitungen implizit beenden, falls StopOffer() zuvor nicht aufgerufen wurde. Frage Q-50d70fb679462321 (offen)

Nutzungspfad

Die typische Verwendung umfasst die Initialisierung, Aktivierung, asynchrone Bearbeitung und Deaktivierung:

1. Eine konkrete Diagnoseklasse erbt von ara::diag::DoIPGroupIdentification und implementiert die Methode GetGidStatus() [SWS_DM_00724].
2. Die Anwendung erzeugt das Objekt mit dem InstanceSpecifier des konfigurierten Port-Prototypes und legt fest, ob GetGidStatus() nebenläufig aufgerufen werden darf (kConcurrent) oder nicht (kNotConcurrent) [SWS_DM_00722].
3. Mittels Offer() schaltet die Anwendung den Handler für das Diagnostic Management scharf [SWS_DM_00725].
4. Sobald DoIP-Anfragen eintreffen, ruft der DM GetGidStatus() auf; die Anwendung liefert den GID-Zustand asynchron über ara::core::Future<GidStatus> zurück [SWS_DM_00724].
5. Vor dem Beenden des Dienstes oder Herunterfahren der Komponente ruft die Anwendung StopOffer() auf [SWS_DM_00726], gefolgt von der Zerstörung des Objekts [SWS_DM_00723].

Sequenzdiagramm: Typischer Ablauf von Instanziierung, Aktivierung, Statusabfrage und Deaktivierung. Quellen: [SWS_DM_00722], [SWS_DM_00724], [SWS_DM_00725], [SWS_DM_00726].

Fehlerszenarien

Beim Einsatz von DoIPGroupIdentification sind Fehlerbedingungen in der Konstruktions- und Bereitstellungsphase definiert:

• Modell- und Zuordnungsfehler (Konstruktor): Schlägt die Instanziierung fehl, werden standardisierte Verletzungen gemeldet [SWS_DM_00722]:
  • InstanceSpecifierMappingIntegrityViolation: Der Bezeichner lässt sich nicht auflösen oder verweist nicht auf einen Port-Prototyp.
  • PortInterfaceMappingViolation: Der referenzierte Port ist nicht als DiagnosticDoIPGroupIdentificationInterface typisiert.
  • ProcessMappingViolation: Dem Ausführungskontext ist im Modell kein passender Prozess zugeordnet.
  • InstanceSpecifierAlreadyInUseViolation: Der angegebene Port-Bezeichner wird im laufenden Prozess bereits von einer anderen Instanz genutzt.
• Dienstbereitstellungsfehler (Offer()): Die Methode gibt ein ara::core::Result<void> zurück. Wurde der Dienst für diesen Handler bereits erfolgreich angeboten, schlägt der erneute Aufruf mit dem Fehlercode DiagOfferErrc::kAlreadyOffered fehl [SWS_DM_00725].
• Fehler bei der Statusabfrage: Die Schnittstelle GetGidStatus() spezifiziert keine standardisierten Fehlercodes [SWS_DM_00724]; anwendungsinterne Fehler müssen über das Ergebnisobjekt des zurückgegebenen Futures abgebildet werden.