DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_ExecutionManagement FIG-423fbdf14dd5bd59 569 × 141 px 1 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 423fbdf14dd5bd59eb19b7c3e01c59893d74a01db85438e4345d42b8c0cb94fc
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-description@2 · erstellt am 2026-10-07

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.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R20-11 → R21-11 keine inhaltliche Änderung Nachfolger: FIG-65458144356f10a2

Keine inhaltlichen Änderungen erkennbar.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of Execution Management AUTOSAR AP R20-11 Figure 7.21: An example deployment of DeterministicSyncMaster in a separate process The Software Lockstep is an optional framework to ensure identical behavior of the redundantly executed processes. The Software Lockstep framework does not necessarily interact with DeterministicSyncMaster, but they can be integrated in order to simplify the control logic and reduce the communication effort over ara::com or other dedicated communication channels. For example the Software Lockstep may also need to understand the state of each execution cycle, in order to give more reasonable and trusty comparison results. Details of Software Lockstep is out of the scope of the current specification, only the possible integration architectures are briefly discussed. Figure 7.22 gives examples of a Software Lockstep framework in library mode and process mode. Details of Software Lockstep will be specified in a later release. Figure 7.22: process mode (left) and library mode (right) integration For process mode of Software Lockstep, the DeterministicSyncMaster functionality can be integrated inside the Software Lockstep as a library. For library mode of Software Lockstep, it can be integrated into the DeterministicSyncMaster process. Figure 7.23 and 7.24 illustrates examples of the possible ways to integrate DeterministicSyncMaster with the Software Lockstep in process mode and library mode for cross domain with two DeterministicSyncMasters.

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R20-11 AUTOSAR_SWS_ExecutionManagement S. 79 7.22 Figure 7.22: process mode (left) and library mode (right) integration
R20-11 AUTOSAR_SWS_ExecutionManagement S. 79 7.22 Figure 7.22: process mode (left) and library mode (right) integration