Figure 9.1: Sequence Diagram for Asynchronous Call with Callback

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Ebene: AUTOSAR Classic Platform (CP), Security-Subsystem über drei Schichten:
  • Application Layer: AUTOSAR Software-Component (SW-C) bzw. BSW-Nutzer.
  • Service Layer: Crypto Service Manager (CSM, BSW-Modul).
  • ECU Abstraction Layer: Crypto Interface (CryIf, BSW-Modul).
  • Microcontroller Abstraction Layer (MCAL) / CDD: Crypto Driver (Crypto, BSW-Modul).
• Funktionaler Zweck: Darstellung des zweiphasigen, nicht-blockierenden Kontrollflusses für asynchrone kryptografische Operationen (CRYPTO_PROCESSING_ASYNC) mit asynchroner Ergebnisbenachrichtigung via Callback-Kaskade.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Modul-Instanzen:
  • Application: Applikations-SW-C bzw. aufrufendes BSW-Modul (z. B. SecOC, KeyM).
  • «module» :Csm: Zentraler Einstiegspunkt für standardisierte Krypto-Dienste; kapselt Service-Verwaltung, Priorisierung und Job-Zuordnung.
  • «module» :CryIf: Abstraktions- und Dispatcher-Schicht; routet logische Kanäle (ChannelId) auf physische Treiber (CryptoDriverObjectId).
  • «module» :Crypto: Hardware-spezifischer Treiber (HSM-, SHE-, Coprozessor- oder Software-Engine).
• Schnittstellen & Operationen:
  • <Service>(): Platzhalter für typspezifische CSM-Service-APIs (z. B. Csm_Hash, Csm_Encrypt, Csm_MacGenerate) bzw. generische Job-Weiterleitungen (CryIf_ProcessJob / Crypto_ProcessJob).
  • Crypto_ProcessJob(Std_ReturnType, uint32, Crypto_JobType**): Interne Kernoperation bzw. Treiber-Dispatcher-Schnittstelle zur asynchronen Abarbeitung des übergebenen Jobs (Crypto_JobType).
  • callback with result: Kaskadierte Benachrichtigung über das Auftragsende (entspricht normativ CryIf_CallbackNotification → Csm_CallbackNotification → applikationsspezifischer Callback / RTE-Event).
  • return(): Synchrone Rückgabe von Ausführungs- und Statuscodes (Std_ReturnType: z. B. E_OK, E_NOT_OK, CRYPTO_E_BUSY, CRYPTO_E_QUEUE_FULL).

3. Dynamisches Verhalten & Sequenzablauf

1. Phase 1: Job-Initialisierung & Dispatching (synchron, blockierungsfrei):
   • Die Application stößt über <Service>() einen kryptografischen Auftrag an :Csm an.
   • :Csm validiert den Aufruf, erzeugt bzw. referenziert den Crypto_JobType und leitet ihn synchron an :CryIf weiter.
   • :CryIf ermittelt anhand der Kanal-Zuordnungstabelle den Zieltreiber und ruft <Service>() auf :Crypto auf.
   • :Crypto reiht den Job in die interne Hardware-/Software-Queue ein und quittiert die Auftragsannahme unmittelbar mit return(E_OK).
   • Der Rückgabewert kaskadiert unverzüglich über :CryIf und :Csm zurück an die Application. Die aufrufende Entität wird nicht blockiert.
2. Phase 2: Asynchrone Ausführung:
   • :Crypto verarbeitet den Job entkoppelt vom Aufruferkontext via Crypto_ProcessJob(...). Die Ausführung erfolgt entweder hardwaregestützt (z. B. per HSM-DMA/Interrupt) oder zeitgesteuert im Kontext der zyklischen Crypto_MainFunction().
3. Phase 3: Ergebnisrückmeldung via Callback-Kaskade:
   • Nach Abschluss der Operation triggert :Crypto den Aufruf callback with result (CryIf_CallbackNotification) an :CryIf.
   • :CryIf leitet das Signal an :Csm (Csm_CallbackNotification) weiter.
   • :Csm aktualisiert den internen Job-Zustand (CRYPTO_JOBSTATE_IDLE) und informiert die Application über den konfigurierten Callback (oder setzt ein RTE-Event).
   • Die Rückkehrpfade (return()) der Callbacks laufen synchron von der Application über :Csm und :CryIf zurück in den Kontext von :Crypto, um den Notification-Vorgang formal zu schließen.

4. Normative Relevanz & Entwickler-Hinweise

• Puffer-Lebensdauer & Reentrancy:
  • Datenpuffer (inputPtr, outputPtr innerhalb von Crypto_JobType) müssen bis zum Eingang des finalen Callbacks im Speicher unverändert und gültig bleiben. Allokationen auf dem lokalen Task-Stack der Applikation führen zu undefiniertem Verhalten / Speicherkorruption.
• Ausführungskontext des Callbacks:
  • Die Callback-Kette läuft typischerweise im Treiber-Kontext ab (ISR oder Task-Kontext der Crypto_MainFunction). Der Applikations-Callback darf keine blockierenden Operationen, Mutex-Waits oder zeitintensiven Berechnungen ausführen, um Verletzungen von Task-Deadlines oder ISR-Latenzen zu verhindern.
• Fehlerbehandlung:
  • Ein synchrones return(E_OK) garantiert ausschließlich die erfolgreiche Annahme bzw. Pufferung des Jobs, nicht dessen erfolgreiche kryptografische Berechnung. Das tatsächliche Operationsergebnis (Std_ReturnType / Crypto_ResultType) wird erst im Parameter des Callbacks übermittelt.
• Konfigurationsabhängigkeit (ARXML):
  • Erfordert konsistente Parametrierung über die Schichten: CsmJobPrimitiveRef, CryIfChannelId gemappt auf den passenden CryptoDriverObjectId, Aktivierung von CsmJobUseAsynchronousJobProcessing = TRUE sowie die Zuweisung eines gültigen Funktionszeigers für den Fertigstellungs-Callback (CsmCallbackNotification).