Figure 7.24: Process Mode with multiple DeterministicSyncMasters

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Technisches Architektur- und Prozess-Deployment-Diagramm (Konzeptuelle Blockarchitektur) der AUTOSAR Adaptive Platform (Execution Management – Deterministic Execution).
• Technischer Zweck: Darstellung der Redundanz- und Synchronisationsarchitektur im sogenannten Process Mode für sicherheitskritische, hochverfügbare Systeme (Fail-Operational / ASIL D).
• Funktionale Einordnung: Adressiert die Verteilung deterministischer Steuerlogik über zwei separate Ausführungsdomänen oder Rechenknoten hinweg. Während im Library Mode die Master-Logik als Bibliothek in den Lockstep-Prozess gelinkt wird, operiert im dargestellten Process Mode der DeterministicSyncMaster als eigenständiger POSIX-Betriebssystemprozess, welcher das Software-Lockstep-Framework kapselt bzw. integriert.

2. Komponenten, Entitäten & Schnittstellen

• DeterministicSync Master 1 & DeterministicSync Master 2 (Rote Konturboxen):
  • Repräsentieren zwei unabhängige Betriebssystem-Prozesse (OS Processes) auf getrennten Rechenknoten, Partitionen oder Prozessordomänen.
  • Agieren als zentrale Koordinationsinstanzen, welche Zyklussteuerung, konsistente Zeittrigger und deterministische Eingangsparameter für angehängte Applikationsprozesse (DeterministicClient) bereitstellen.
• TimeSync Slave 1 & TimeSync Slave 2 (Blaue Innenboxen):
  • Lokale Instanzen/Endpunkte des AUTOSAR Time Synchronization Stacks (ara::tsync bzw. IEEE 802.1AS / gPTP).
  • Liefern die synchronisierte globale Zeitbasis an den jeweiligen DeterministicSyncMaster, um Phasendrift und Laufzeitunterschiede der physikalischen Clocks zu eliminieren.
• Software Lockstep 1 (Orange Box, durchgezogene Linie):
  • Aktives Software-Lockstep-Modul/Framework innerhalb der Master-1-Domäne zur Erkennung transienter/permanenter Rechenfehler über redundante Ausführung und Datenvergleich (Voter/Comparator).
• Software Lockstep 2 (Orange Box, gestrichelte Kontur):
  • Optionale, sekundäre oder asymmetrische Lockstep-Instanz. Die gestrichelte Darstellung indiziert herstellerspezifische Implementierungsfreiheit: Je nach Sicherheitsarchitektur agiert Knoten 2 als vollwertiger redundanter Lockstep-Knoten, passiver Shadow-Knoten oder reiner Vergleicher/Empfänger.
• Roter Doppelpfeil (Inter-Master-Schnittstelle):
  • Deterministischer Synchronisationskanal (Synchronization Channel) zwischen beiden Master-Instanzen (z. B. via Ethernet/TSN, PCIe oder deterministischem IPC). Dient dem Austausch von Abstimmungsdaten zur Herbeiführung der finalen Zyklusentscheidung (Final Decision).

3. Dynamisches Verhalten & Sequenzablauf

1. Aktivierungsanforderung ([SWS_EM_01325]):
   • Redundante Applikationsprozesse (DeterministicClient) rufen ara::exec::DeterministicClient::WaitForActivation() auf und senden eine Synchronisationsanfrage (Sync Request) an ihren jeweils zugeordneten lokalen DeterministicSyncMaster.
2. Zeitbasierte Zustandserfassung:
   • Jeder Master liest über seinen TimeSync Slave den aktuellen globalen Zeitstempel aus.
3. Master-Cross-Synchronisation (Inter-Master-Konsens via Synchronisationskanal):
   • Master 1 und Master 2 tauschen über den Synchronisationskanal Statusinformationen, Zykluszähler und die vom Software-Lockstep erzeugten Prüfsummen/Vergleichsdaten aus.
   • Gemäß M-out-of-N-Policy (MooN) bzw. Mehrheitsentscheid einigen sich beide Instanzen auf einen konsistenten globalen Ausführungszeitpunkt und Zykluscode (Final Decision).
4. Zyklusfreigabe ([SWS_EM_01326]):
   • Die Master senden zeitgleich eine Synchronisationsantwort (Sync Response) mit dem berechneten Aktivierungszeitstempel (ActivationTime) an ihre lokalen Clients zurück.
5. Divergenz- und Fehlerbehandlung ([RS_EM_00053]):
   • Tritt eine Diskrepanz zwischen Master 1 und Master 2 auf (Kommunikationsabbruch auf dem Sync-Kanal, ungleiche Lockstep-Hashes oder verletzte Zyklus-Deadlines), triggert der Software-Lockstep definierte Degradierungsstufen (z. B. Übergang in den Safe-State, Isolation des fehlerhaften Knotens oder Umschaltung auf Primärbetrieb).

4. Normative Relevanz & Entwickler-Hinweise

• Scheduling- und Task-Design: Da beide Master als getrennte POSIX-Prozesse laufen, unterliegen sie dem OS-Scheduler (z. B. Real-Time-Prioritäten via SCHED_FIFO). Die Latenz des Synchronisationskanals zwischen Master 1 und Master 2 geht direkt in die Worst-Case Execution Time (WCET) des WaitForActivation()-Zyklus ein.
• TimeSync-Abhängigkeit: Ein synchroner Lockstep-Betrieb ist nur zulässig, wenn beide TimeSync Slaves den Status Synchronized melden. Entwickler müssen Timeouts und Clock-Drifts im Synchronisationskanal explizit über das Execution Manifest (ExecutionManifest.arxml) abfangen.
• Herstellerspezifische Ausprägung (Vendor Specific): Das Zusammenspiel des Synchronisationskanals mit dem Software Lockstep (insb. die gestrichelte Entität Software Lockstep 2) ist im AUTOSAR-Standard nicht binär vorgegeben, sondern plattformspezifisch. Der Stack-Integrator muss sicherstellen, dass die IPC-/Netzwerktreiber des Synchronisationskanals deterministisch und jitterarm parametriert sind.
• Applikationstransparenz: Für Entwickler von Funktionssoftware (DeterministicClient) bleibt die Cross-Domain-Master-Synchronisation vollständig transparent; der Aufrufvertrag beschränkt sich normativ auf die ara::exec-Standard-APIs.