Figure 7: 4 AUTOSAR Layered View with channels

1. Diagrammtyp & Architektur-Kontext

Statisches Architektur- und Schichtenmodell (AUTOSAR Layered View) des AUTOSAR Classic Krypto-Stacks mit vertikalen logischen Kanalstrukturen (Channels). Das Diagramm veranschaulicht die Einbettung des Crypto Service Managers (CSM) in die AUTOSAR-Basissoftware (BSW) sowie die hierarchische Weiterleitung kryptografischer Anfragen von der Applikationsebene bis zur zugrundeliegenden Hardware (Microcontroller/HSM) über standardisierte Zwischenschichten.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm gliedert sich vertikal in Software- (SW) und Hardware-Ebenen (HW):

• Application Layer: Beinhaltet mehrere Software-Komponenten/Applikationen (App1, App2, App3), die spezifische Krypto-Dienste anfordern (App1: AES, App2: AES, App3: RSA).
• Runtime Environment (RTE): Vermittelt Schnittstellenaufrufe zwischen Application Layer und BSW.
• Service Layer: Beherbergt den CSM (Standard), der funktionale Krypto-Jobs entgegennimmt und über logische Kanäle verwaltet.
• ECU Abstraction Layer: Enthält das Crypto Interface (CryIf), welches als Abstraktions- und Routing-Instanz dient.
• Microcontroller Abstraction Layer (MCAL): Enthält den hardwarenahen Crypto Driver (Crypto).
• Complex Drivers (CDD): Schichtenübergreifender Block parallel zu Service Layer, ECU Abstraction Layer und MCAL.
• Microcontroller (HW): Beinhaltet ein Hardware Security Module (HSM) mit Hardware-Krypto-Engines (HW-AES, HW-RSA).
• Logische Kanäle & Schnittstellen:
  • Channel HW-AES: Führt von CSM durch Crypto Interface und Crypto Driver zu HW-AES. Weist Priorisierungen bzw. Sub-Kanäle auf (AES low, AES high).
  • Channel HW-RSA: Führt von CSM durch Crypto Interface und Crypto Driver direkt zu HW-RSA.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm stellt die Verteilung und Pufferung von Krypto-Aufträgen über zwei dedizierte Queuing-Stufen dar:

1. Auftragsinitiierung: Applikationen übergeben asynchrone oder synchrone Krypto-Jobs über die RTE an den CSM (App1 und App2 adressieren AES-Dienste, App3 RSA-Dienste).
2. CSM Queuing: Im Service Layer existiert für jeden Kanal eine konfigurierbare Warteschlange (CSM queuing), die Aufträge puffert, falls nachgelagerte Kanäle oder Treiber beschäftigt sind.
3. Routing: Das Crypto Interface leitet die Kanäle (Channel HW-AES, Channel HW-RSA) transparent an den zuständigen Crypto Driver weiter.
4. Crypto Driver Queuing: Im MCAL-Treiber erfolgt eine hardwarenahe Pufferung (Crypto driver queuing), insbesondere differenziert nach Prioritätsstufen (dargestellt am AES-Kanal mit AES low und AES high).
5. Hardwareausführung: Die Jobs werden an die entsprechenden Hardware-Beschleuniger des HSM (HW-AES, HW-RSA) zur Ausführung übergeben.

4. Normative Relevanz & Entwickler-Hinweise

Für Systemintegratoren und BSW-Entwickler verdeutlicht die Abbildung die zweistufige Warteschlangen-Architektur (CSM queuing vs. Crypto driver queuing):

• Das Kanalrouting muss im CSM und Crypto Interface konsistent auf die Treiberobjekte und Hardwarekanäle des Crypto Drivers abgebildet werden.
• Mehrere Applikationen (App1, App2) können denselben logischen Hardwarekanal (Channel HW-AES) nutzen; die Serialisierung und Priorisierung erfolgt über die Queues im CSM bzw. Crypto Driver.
• Bei der Konfiguration von Kanälen mit unterschiedlichen Prioritäten (AES low vs. AES high) ist sicherzustellen, dass hardwarenahe Treiberqueues und Preemption-Strategien des Treibers passend zu den Latenzanforderungen der jeweiligen Applikationen ausgelegt sind.