Figure 7.7: Example of threshold filter

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Zeitverlaufs-/Timing-Diagramm mit diskreter Zeitbasis (num_timer_calls) und parallelen Event-/Trigger-Spuren.
• Funktionale Einordnung: AUTOSAR Classic Platform (R20-11), BSW-Modul IdsM (Intrusion Detection System Manager, Service Layer, ISO 21434 / On-Board Security).
• Technischer Zweck: Spezifikation des deterministischen Filter- und Durchleitungsverhaltens des IdsM Threshold Filters für ein Security Event (SEv, j = 47). Der Filter dient der Ratenbegrenzung und Dämpfung von Security Events (z. B. bei Flooding-/Brute-Force-Angriffen), um nachgelagerte Stacks (NVRAM, CAN/Ethernet-Transceiver, IDS-Reporter) vor Überlast zu schützen.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Modul-Instanzen:
  • IdsM: Verarbeitende BSW-Entität.
  • Event-Quelle (BSW-Sensor oder SW-C): Triggert eingehende Ereignisse über das IdsM-API (IdsM_SetEventStatus / IdsM_ReportEvent).
  • Event-Senke: Empfänger von weitergeleiteten Ereignissen (forward(...) an PDU-Router, NVRAM Manager oder IdsR).
• Datenstrukturen:
  • Event: Repräsentiert eine Security Event Instance (SEv) bestehend aus:
    • event_id: Eindeutige Ereigniskennung (j = 47).
    • count: Ereignisanzahl pro Meldung (im Diagramm normiert mit count = 1).
    • context_data: Diagnose- und Kontext-Payload (z. B. Byte-Arrays {0x23}, {0x11}, {0x42}, {0x33}, {0x55}, {0xAA}).
• Konfigurationsparameter (IdsM BSW-Konfiguration):
  • IdsMEventThresholdTimeInterval (l_j): Filterintervall-Dauer, parametriert als Vielfaches der Zykluszeit T_min (l_47 = 2).
  • IdsMEventThresholdNumber (p_j): Schwellwert-Anzahl (p_47 = 3).
  • IdsMMainFunctionPeriod (T_min): Periodizität der zyklischen Hauptfunktion IdsM_MainFunction(), welche die diskreten Ticks (num_timer_calls 0, 1, 2, 3, 4) treibt.
• Interne Signale & Spuren:
  • Incoming Events: Asynchrone Eingangsmeldungen von SEv 47.
  • Outgoing Events: Synchron oder gepuffert weitergeleitete Meldungen.
  • Counter Resets / OnThresholdTimer(): Periodischer Intervall-Timeout zur Re-Initialisierung des Zählers.

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierung: Das Zählen des Intervalls startet strikt mit dem ersten Aufruf von IdsM_MainFunction() ([SWS_IdsM_01065]). Die Zeitbasis ist diskret in Einheiten von IdsMMainFunctionPeriod unterteilt.
• Intervall 1 (t ∈ [0, 2[; l_47 = 2 Ticks):
  1. t ≈ 0.5: Eingang von Event(id=47, count=1, context_data={0x23}) → interner Zähler = 1. Da Zähler < p_47 (1 < 3), wird das Event verworfen (dropped).
  2. t ≈ 1.7: Eingang von Event(id=47, count=1, context_data={0x11}) → interner Zähler = 2. Da Zähler < p_47 (2 < 3), wird das Event verworfen.
  3. t = 2.0: Ablauf des Intervalls 1 (num_timer_calls = 2). Triggerung von OnThresholdTimer() → Event-Zähler wird gem. [SWS_IdsM_01063] hart auf 0 zurückgesetzt. Während des gesamten Intervalls 1 erfolgt keine Weiterleitung (Outgoing Events leer).
• Intervall 2 (t ∈ [2, 4[; l_47 = 2 Ticks):
  1. t ≈ 2.1: Eingang von Event(id=47, count=1, context_data={0x42}) → interner Zähler = 1 → verworfen (1 < 3).
  2. t ≈ 2.6: Eingang von Event(id=47, count=1, context_data={0x33}) → interner Zähler = 2 → verworfen (2 < 3).
  3. t ≈ 3.1: Eingang von Event(id=47, count=1, context_data={0x55}) → interner Zähler = 3. Schwellwert p_47 = 3 ist erreicht → Event wird unverzüglich via forward(...) an die Ausgangsspur übergeben.
  4. t ≈ 3.7: Eingang von Event(id=47, count=1, context_data={0xAA}) → interner Zähler = 4. Bedingung Zähler ≥ p_47 bleibt erfüllt → Event wird ebenfalls sofort via forward(...) weitergeleitet.
  5. t = 4.0: Ablauf des Intervalls 2 (num_timer_calls = 4). Triggerung von OnThresholdTimer() → Zähler-Reset auf 0.

4. Normative Relevanz & Entwickler-Hinweise

• **Semantik des Schwellwerts (Pass-After-Threshold):** Der Filter blockiert die ersten p - 1 Vorkommnisse innerhalb eines Fensters. Erst ab dem p-ten Ereignis schaltet der Filter bis zum Ende des aktuellen Intervalls l_j auf transparenten Durchlass.
• Kontextdaten-Verlust: Die context_data der ersten p - 1 Events werden nicht akkumuliert oder zwischengespeichert, sondern unwiederbringlich verworfen. Sicherheitsrelevante Forensik-Daten aus der Initialphase eines Vorfalls stehen im Backend/IdsR nicht zur Verfügung.
• Konfigurations-Integrität:
  • Gemäß [SWS_IdsM_01064] muss gelten: IdsMEventThresholdTimeInterval = k · IdsMMainFunctionPeriod mit $k \in \mathbb{N}_{\ge 1}$. Ungültige Konfigurationen müssen vom BSW-Konfigurator zur Generierungszeit abgefangen werden.
  • Wenn p = 1 konfiguriert wird, entfällt die Filterwirkung (jedes Event wird sofort weitergeleitet).
• Kein gleitendes Fenster (Tumbling Window): Der Mechanismus arbeitet mit festen Blockintervallen (tumbling/fixed window), nicht mit einem gleitenden Fenster (sliding window). Tritt ein Burst phasenversetzt über die Intervallgrenze auf (z. B. 2 Events kurz vor Tick 2 und 2 Events kurz nach Tick 2), wird die Schwelle p=3 in keinem der beiden Intervalle erreicht, obwohl 4 Events in engem zeitlichem Abstand empfangen wurden.
• RAM-Footprint & Task-Kontext: Pro aktiver Event-ID mit Schwellwertfilter müssen im IdsM-RAM mindestens ein Zähler (uint16/uint8 für p) sowie ein Tick-Zähler (uint16/uint32 für l) vorgehalten werden. Der Reset erfolgt im Kontext der IdsM_MainFunction(), während die Inkrementierung synchron im Aufruferkontext der Reporting-API stattfindet (kritischer Abschnitt / Mutex-Schutz gegen Nebenläufigkeit erforderlich).