Figure 7.20: Sequence Diagram of the Synchronization Control Messages with single DeterministicSyncMaster

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck & Einordnung: Spezifikation des deterministischen Synchronisationsmechanismus in der AUTOSAR Adaptive Platform (Execution Management, ara::exec, R20-11). Das Diagramm modelliert das Zusammenspiel zwischen mehreren deterministischen Applikationsprozessen (DeterministicClient) und einer zentralen Takt-/Synchronisationsinstanz (DeterministicSyncMaster) zur Gewährleistung replizierter oder koordinierter zyklusbasierter Ausführung über servicebasierte Interprozess-/Inter-ECU-Kommunikation (ara::com).

2. Komponenten, Entitäten & Schnittstellen

• Lebenslinien & Akteure:
  • Application Process APP1 / Application Process APP2: Adaptive Application Processes (POSIX-Prozesse), die deterministische Berechnungszyklen ausführen.
  • APP1::DeterministicClient Client_1 / APP2::DeterministicClient Client_2: Prozesslokale Instanzen der Klasse ara::exec::DeterministicClient.
  • DeterministicSyncMaster Master_1: Zentraler Synchronisationsknoten (Sync-Master-Prozess) innerhalb der deterministischen Synchronisationsdomäne.
• Schnittstellen & Interaktionspunkte:
  • Prozessintern (API): ara::exec::DeterministicClient::WaitForNextActivation() – synchrone Blockier-API des Clients zur Steuerung des Prozessfortschritts.
  • Prozessübergreifend (IPC / ara::com):
    • Request-Channel: ara::com::send(SyncRequest) vom Client an den Master.
    • Response-Channel: ara::com::send(SyncResponse) vom Master an den Client.
• Kardinalitäten & Beziehungen:
  • 1:n-Beziehung: Genau ein DeterministicSyncMaster synchronisiert n DeterministicClients (im Diagramm exemplarisch n=2).
  • 1:1-Komposition: Jeder deterministische Applikationsprozess bindet exakt eine DeterministicClient-Instanz ein.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialer Wartezustand: Master_1 befindet sich im blockierenden bzw. lauschenden Zustand (WaitForRequest()).
2. Zyklusabschluss & Synchronisationsanfrage APP1:
   • APP1 beendet seinen Berechnungsabschnitt und ruft synchron WaitForNextActivation() an Client_1 auf. Der Thread von APP1 wird blockiert.
   • Client_1 generiert und sendet asynchron über ara::com die Nachricht SyncRequest an Master_1.
3. Synchronisationsanfrage APP2:
   • APP2 ruft zeitversetzt WaitForNextActivation() an Client_2 auf; APP2 blockiert.
   • Client_2 sendet SyncRequest via ara::com an Master_1.
4. Master-Berechnung (CalculateNextCycle()):
   • Sobald die Master-Synchronisationspolicy erfüllt ist (z. B. Eintreffen aller erwarteten Requests vor einer Deadline), berechnet Master_1 die Aktivierungsparameter des Folgezyklus (insbesondere deterministischer Ziel-Timestamp).
5. Aktivierungs-Dispatch (SyncResponse):
   • Master_1 sendet über ara::com die SyncResponse (inklusive Ziel-Aktivierungszeitstempel) an Client_1 und Client_2.
6. Parallele Reaktivierung:
   • Gemäß Spezifikationsnotiz synchronisieren sich beide Clients lokal auf den im Payload enthaltenen absoluten Zeitstempel ("Next cycle should be triggered simultaneously based on the activation timestamp in the response message").
   • Nach Ablauf bis zum Zielzeitpunkt kehrt der blockierende Aufruf WaitForNextActivation() mit dem Status :kRun (ara::exec::ActivationReturnType::kRun) an APP1 und APP2 zurück; beide Prozesse starten deterministisch synchron ihren nächsten Rechenzyklus.

4. Normative Relevanz & Entwickler-Hinweise

• API-Vertrag (SWS_EM_01304): Wenn ein DeterministicClient für die Verwendung eines DeterministicSyncMaster konfiguriert ist, muss er sich bei jedem Aufruf von WaitForNextActivation() über diesen Mechanismus abgleichen.
• Transportabstraktion: Obwohl das Sequenzdiagramm ara::com als Transportlayer zeigt, schreibt AUTOSAR dies nicht zwingend vor; proprietäre Low-Latency-IPC- oder Hardware-basierte Synchronisationskanäle sind herstellerspezifisch zulässig.
• Synchronisations-Policies & Deadlines: Der Master benötigt eine definierte Quorum-/Timeout-Policy (z. B. n-von-m-Muster oder Worst-Case-Deadline). Entwickler müssen Timeouts und Fehlerzustände abfangen (z. B. wenn ein Client ausfällt oder verspätet antwortet).
• Jitter & Scheduling-Latenzen: Der berechnete Ziel-Timestamp in SyncResponse muss zwingend die Kommunikationslaufzeit (ara::com / SOME/IP / IPC-Stack) plus OS-Scheduling-Jitter übersteigen, damit alle Clients den gemeinsamen Zeitpunkt in der Zukunft verlässlich treffen können, ohne dass kRun verfrüht oder asynchron ausgelöst wird.