Figure 7.22: process mode (left) and library mode (right) integration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informelles Architektur- und Deployment-Diagramm (Prozess-/Container-Kapselungsmodell).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster Execution Management (EM), Sub-Bereich Deterministic Execution / Software Lockstep.
• Technischer Zweck: Gegenüberstellung der beiden Integrationsmuster zur Koppelung des Software Lockstep Frameworks mit dem DeterministicSyncMaster:
  • Links (Process Mode): Software Lockstep bildet den übergeordneten OS-Prozess; DeterministicSyncMaster ist als Bibliothek eingebettet.
  • Rechts (Library Mode): DeterministicSyncMaster bildet den übergeordneten OS-Prozess; Software Lockstep ist als Bibliothek eingebettet.
• Architekturziel: Minimierung von IPC-Overhead (ara::com, Shared Memory, OS-Pipes) und Latenzen bei der Statusübertragung deterministischer Ausführungszyklen an den Lockstep-Voter/Komparator für redundante Prozesse (Safety-Integrität gem. ISO 26262).

2. Komponenten, Entitäten & Schnittstellen

• Software Lockstep (gelber Container / Block):
  • Framework zur Sicherstellung identischen Laufzeitverhaltens redundant ausgeführter Prozesse (Zustands- und Ausgangsdatenvergleich).
  • Process Mode (links): Trägerprozess (eigenständiger POSIX-Address Space, UID/GID, OS-Scheduling-Entity).
  • Library Mode (rechts): Linkbare Software-Bibliothek (statisch/dynamisch) innerhalb des DeterministicSyncMaster-Prozesskontexts.
• DeterministicSyncMaster (rot umrandeter Container / Block):
  • Koordinator für deterministische Ausführungszeitpunkte und Zyklus-Trigger der DeterministicClients.
  • Process Mode (links): Als Bibliothek in den Software Lockstep-Prozess integriert.
  • Library Mode (rechts): Eigenständiger POSIX-Prozess, der den Hauptausführungskontext bereitstellt.
• TimeSync Slave (weißer Sub-Block):
  • Untergeordnete Komponente/Schnittstelle des DeterministicSyncMaster zur Synchronisation auf eine externe globale Zeitbasis (z. B. IEEE 802.1AS / gPTP / StbM).
  • In beiden Modi strikt an den DeterministicSyncMaster gebunden (Kardinalität 1:1, Composition).
• Schnittstellen & Bindung:
  • Durch die Co-Location (Library-in-Process) entfällt die Middleware-Schicht (ara::com). Die Kopplung erfolgt prozessintern über C++-In-Process-APIs bzw. direkte Funktionsaufrufe anstelle serialisierender IPC.

3. Dynamisches Verhalten & Sequenzablauf

• Zyklischer Wirkablauf:
  1. Zeitsynchronisation: Der TimeSync Slave empfängt periodisch Zeitinformationen von der Plattform-Zeitsynchronisation und gleicht den lokalen Timer des DeterministicSyncMaster ab.
  2. Cycle State Notification: Zu Beginn/Ende jedes deterministischen Ausführungszyklus übergibt der DeterministicSyncMaster den Zyklusstatus (Cycle State, Zyklusindex, Zeitschranken) prozessintern an das Software Lockstep Framework.
  3. Lockstep-Vergleich: Das Software Lockstep Framework nutzt diese Zyklusinformation, um Ein- und Ausgabedaten der redundant berechneten Prozessinstanzen phasen- und zyklusgenau abzugleichen.
• Synchronisationspfad: Rein synchroner In-Memory-Call-Stack; keine asynchronen IPC-Kontextwechsel oder Blockaden durch IPC-Warteschlangen.
• Fehlerbehandlung: Divergenzen redundanter Berechnungen werden direkt im Lockstep-Kontext detektiert und können ohne IPC-Verzögerung an das Execution Management bzw. Platform Health Management (PHM) eskaliert werden.

4. Normative Relevanz & Entwickler-Hinweise

• Spezifikationsstatus (R20-11): Non-normatives Architekturbeispiel („Details of Software Lockstep is out of the scope of the current specification“). Dient als Integrationsleitfaden für System- und Safety-Architekten bis zur finalen Standardisierung.
• Auswahlkriterien für Integratoren:
  • Process Mode (Software Lockstep als Host): Empfohlen, wenn der Lockstep-Mechanismus die primäre Steuerungs- und Überwachungsinstanz der ECU darstellt und deterministische Synchronisation lediglich als Hilfsdienst fungiert.
  • Library Mode (DeterministicSyncMaster als Host): Empfohlen, wenn die deterministische Zeittaktung und Scheduling-Koordination das primäre Framework bildet und der redundante Lockstep-Vergleich als Safety-Plugin/Add-on zugeschaltet wird.
• Safety & ASIL-Dekomposition:
  • Durch das In-Process-Design teilen sich DeterministicSyncMaster und Software Lockstep denselben Adressraum (Freedom from Interference auf Speicherebene muss über gemeinsamen ASIL oder strenge MPU-/MMU-Konzepte innerhalb des Prozesses bzw. qualifizierten Compiler-Code nachgewiesen werden).
• Ressourceneffizienz: Vermeidet Context-Switching-Overhead und IPC-Pufferlatenzen; optimiert für harte Echtzeit- und Safety-Anforderungen mit extrem engen Toleranzfenstern.