Figure 7.4: Use of Event Buffers and Context Data Buffers

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Datenfluss- und Speicherarchitektur-Diagramm (Pufferzuweisungs- und Verknüpfungsmodell / Queueing-Mechanismus).
• Funktionale Einordnung: AUTOSAR Classic Platform, BSW-Sicherheitsarchitektur, Intrusion Detection System Manager (IdsM).
• Technischer Zweck: Visualisierung des deterministischen Speicher- und Entkopplungsmodells zwischen synchronem Empfang von Security Events (SEv via API) und deren asynchroner Weiterverarbeitung im zyklischen Taskkontext (IdsM_MainFunction). Zeigt die Trennung von fest dimensionierten Event-Metadaten und variabel dimensionierten Kontextdaten (Context Data) zur Vermeidung dynamischer Speicherallokation im automobilen Steuergerät.

2. Komponenten, Entitäten & Schnittstellen

• Event Buffer Pool (Links):
  • Pufferpool für Event-Deskriptoren/Metadaten fester Größe (z. B. Event-ID, Zeitstempel, Zähler, Filterstatus).
  • Verwaltet als Freispeicherliste/Ringpuffer mit fester Elementanzahl (statisch konfiguriert).
• Context Data Buffer Pool (Mitte):
  • Mehrstufiger Pufferpool mit statisch partitionierten Speicherblöcken unterschiedlicher Größe (Size, diskrete Blockgrößen) und Belegungsstatus (Status: Unused vs. In Use).
  • Realisiert ein deterministisches Best-Fit-/First-Fit-Verfahren („most adequate size“) ohne Heap-Fragmentierung (malloc-Verbot).
• Event Data Buffer Filled (Unten, blau):
  • Konkrete Instanz eines aus dem Event-Pool allozierten und mit SEv-Basisdaten beschriebenen Pufferelements.
• Optional Context Data Buffer Linked (Mitte-Unten, orange):
  • Zugewiesener Kontextdatenpuffer aus dem Context-Pool; über Pointer bidirektional bzw. referentiell fest an den Event Data Buffer gekoppelt (Linked).
  • Nur aktiv, wenn das gemeldete SEv Nutzdaten/Payload (z. B. CAN-Frame-Dump, PDU-Fragmente) mitführt.
• Collection of events to be processed asynchronously (Rechts):
  • Asynchrone FIFO-Queue/Event-Warteschlange zur Übergabe an die interne Filter- und Qualifizierungs-Pipeline der MainFunction.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger / API-Aufruf (Synchroner Pfad):
   • Ein Software-Sensor (BSW-Modul wie CanSM, SecOC oder SW-C via RTE) meldet ein Security Event über IdsM_SetSecurityEvent().
2. Event-Pufferallokation:
   • Entnahme eines freien Blocks aus dem Event Buffer Pool. Tritt ein Pufferüberlauf auf (Pool erschöpft), greift die konfigurierte Pufferüberlaufstrategie (Drop Event, Logging via Det/Dem).
3. Kontextdaten-Allokation & Modifikation (Optional):
   • Führt das SEv Kontextdaten mit, ermittelt der IdsM im Context Data Buffer Pool den kleinstmöglichen Block, dessen Kapazität mindestens contextDataSize entspricht.
   • Gemäß [SWS_IdsM_00750] (Upstream: RS_Ids_00200): Ist ein Context Data Modifier konfiguriert (IdsMContextDataModifierCallout) und der Reporting-Modus DETAILED oder DETAILED_BYPASSING_FILTERS, wird der Callout synchron unmittelbar nach Meldung des SEv ausgeführt, um Kontextdaten vor Pufferung zu modifizieren/anzupassen.
   • Markierung des gewählten Kontextblocks als In Use und logische Verknüpfung mit dem Event-Puffer.
4. Einreihung in asynchrone Queue:
   • Übergabe des verknüpften Pufferpaars (Event Data Buffer + optionaler Context Data Buffer) in die Collection of events to be processed asynchronously.
5. Asynchrone Abarbeitung (IdsM_MainFunction):
   • Zyklisches Auslesen der Queue im Task-Kontext.
   • Ausführung der IdsM-Filterketten (Stateful-, Threshold-, Frequency-Filter) und PDU-Aggregation (QvIs-PDU-Generierung).
   • Nach Verarbeitung oder Filter-Verwerfung: Rückgabe beider Puffer in ihre jeweiligen Freispeicher-Pools (Status wechselt wieder auf Unused).

4. Normative Relevanz & Entwickler-Hinweise

• Speicherdimensionierung (BSW-Konfiguration):
  • Die Größenklassen und Instanzanzahlen beider Pools müssen zur Generierungszeit über die Parameter IdsMEventBufferPool und IdsMContextDataBufferPool im AUTOSAR-Toolchain-Editor präzise dimensioniert werden.
  • Eine Fehlkonfiguration der Puffergrößenklassen führt zu Fragmentierungsverschnitt oder zu Pufferabwürfen unter Last.
• Interrupt-Sicherheit & Kritische Abschnitte:
  • Da IdsM_SetSecurityEvent() aus ISR- oder preemptiven Task-Kontexten aufgerufen werden kann, müssen die Puffer-Zuweisung und der Statuswechsel (Unused → In Use) durch Schollsperren (SchM_Enter_IdsM_... / SchM_Exit_IdsM_...) vor Race Conditions geschützt sein.
• Zero-Copy & Effizienz:
  • Der Entwickler von IdsMContextDataModifierCallout muss sicherstellen, dass die Modifikation in-place bzw. mit minimaler Latenz erfolgt, da dieser Callout den synchronen Pfad des meldenden Treibers/der SW-C blockiert.
• Lebenszyklus von Zeigern:
  • Die an IdsM_SetSecurityEvent() übergebenen Kontextdaten-Zeiger dürfen vom Aufrufer nach Rückkehr der Funktion verworfen werden; der IdsM kopiert die Daten zwingend in den reservierten Context-Puffer, bevor die API zurückkehrt.