Figure 8.4: UDS Transport Channel Reestablishment 134 of 312 — AUTOSAR CONFIDENTIAL —

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm (seq Channel Reestablishment beyond lifecycle) im Kontext der AUTOSAR Adaptive Platform (SWS Diagnostics / Diagnostic Management). Das Diagramm spezifiziert die Persistierung und Wiederherstellung eines UDS-Transportkanals über den Prozesslebenszyklus (Shutdown und nachfolgender Neustart) des Diagnostic Managers hinweg.

2. Komponenten, Entitäten & Schnittstellen

• DM Instance: DM_Generic: Instanz des generischen Diagnostic Managers; implementiert die Schnittstelle UdsTransportProtocolMgr.
• Instance1: UdsTransportProtocolHandlerImpl: Erste Instanz des UDS-Transportprotokoll-Handlers vor dem Herunterfahren.
• Instance2: UdsTransportProtocolHandlerImpl: Zweite Instanz des UDS-Transportprotokoll-Handlers im darauffolgenden Prozesslebenszyklus.
• Schnittstellen & Methoden:
  • UdsTransportProtocolHandler(UdsTransportProtocolHandlerID, UdsTransportProtocolMgr&): Konstruktor zur Instanziierung und Übergabe des Managers.
  • Initialize(): Synchrone Initialisierung des Handlers.
  • Start(): Starten des Protokoll-Handlers.
  • Stop(): Aufforderung zum Stoppen des Handlers.
  • HandlerStopped(UdsTransportProtocolHandlerID): Rückmeldung des Handlers an den Manager über den erfolgten Stopp.
  • ~UdsTransportProtocolHandler(): Destruktor zur Freigabe der Handler-Instanz.
  • NotifyReestablishment(ChannelID): bool: Benachrichtigung des Handlers durch den DM zur Anforderung einer Kanal-Wiederherstellung.
  • ChannelReestablished(GlobalChannelIdentifier): Asynchroner Callback des Handlers an den Manager zur Bestätigung des wiederhergestellten Kanals.
• Referenzierter Interaktionsrahmen: ref UDS Request Processing on a specific ChannelID.

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf gliedert sich über Lebenszyklusphasen des Diagnostic Managers:

1. [DM Startup]: DM_Generic instanziiert Instance1: UdsTransportProtocolHandlerImpl über den Konstruktor UdsTransportProtocolHandler(UdsTransportProtocolHandlerID, UdsTransportProtocolMgr&) und ruft Initialize() auf, welches synchron quittiert wird.
2. [DM Run]: DM_Generic ruft Start() auf. Nach regulärer Verarbeitung (ref UDS Request Processing on a specific ChannelID) fordert DM_Generic über NotifyReestablishment(ChannelID): bool die Persistierung des Kanals an. Instance1 führt intern Persist network/transport protocol specific info, which identifies this ChannelID() aus und bestätigt den Aufruf.
3. [DM Shutdown]: DM_Generic ruft Stop() an Instance1 auf. Nach Abschluss meldet Instance1 via HandlerStopped(UdsTransportProtocolHandlerID) den Vollzug. Anschließend ruft DM_Generic den Destruktor ~UdsTransportProtocolHandler() auf, wodurch die Lebenslinie von Instance1 endet.
4. [DM Next Startup]: DM_Generic instanziiert nach Neustart eine neue Instanz Instance2: UdsTransportProtocolHandlerImpl via Konstruktor, gefolgt von synchronem Initialize() und Start().
5. [DM Next Run]: Sobald die Verbindung auf Transportebene verfügbar ist (Channel with ChannelID becomes available()), meldet Instance2 die erfolgreiche Reetablierung an DM_Generic mittels ChannelReestablished(GlobalChannelIdentifier).

4. Normative Relevanz & Entwickler-Hinweise

• Persistenzmechanismus: Handler-Implementierungen müssen kanalspezifische Netzwerk- und Adressierungsinformationen nichtflüchtig ablegen, wenn NotifyReestablishment signalisiert wird, damit derselbe logische Transportkanal nach einem ECU- oder DM-Neustart eindeutig wiedererkannt wird.
• Zustandsübergänge & Synchronisation: Das Herunterfahren erfordert ein kontrolliertes Quittieren via HandlerStopped vor Aufruf des Destruktors, um Datenverlust bei der Persistierung zu verhindern.
• Identifikatoren: Die Zuordnung wechselt zwischen lokaler ChannelID bzw. UdsTransportProtocolHandlerID innerhalb des Managers und dem plattformweit eindeutigen GlobalChannelIdentifier beim Wiederherstellungs-Callback ChannelReestablished.