Figure 7.26: ActionList timeout

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Objektdiagramm / Konfigurations-Instanzdiagramm (ARXML-Manifest-Konfigurationssemantik).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (SM).
• Technischer Zweck: Veranschaulichung der hierarchischen Konfigurations- und Override-Semantik für die Laufzeitüberwachung (maxActionListDuration) von Aktionslisten (ActionList) im State Management Manifest. Das Diagramm visualisiert das Auflösen von Standard-Timeouts auf Modulebene versus elementspezifischen Timeouts auf Instanzebene zur Vermeidung blockierender Zustandsübergänge.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Stereotypen:
  • «StmModuleInstantiation»: Repräsentiert die konkrete Prozess-/Modul-Instanziierung des State Managements auf einer Adaptive Machine.
    • Attribut: maxActionListDuration : 300 (Globaler Standard-Timeout-Schwellenwert in Zeiteinheiten/ms).
  • «ActionList»: Ausführungseinheiten des State Managements, bestehend aus sequenziellen oder parallelen Einzelaktionen (z. B. Prozesssteuerungs-Kommandos via Execution Management, IPC-Aufrufe, Diagnostic Reset Requests).
    • ActionList1: Keine lokale Dauer deklariert; referenziert/übernimmt den globalen Standardwert.
    • ActionList2: Lokales Attribut maxActionListDuration : 60.
    • ActionList3: Keine lokale Dauer deklariert; referenziert/übernimmt den globalen Standardwert.
    • ActionList4: Lokales Attribut maxActionListDuration : 600.
• Beziehungen & Semantik:
  • Assoziation (durchgezogene Linie): Strukturelle Zuordnung der konfigurierten ActionList-Instanzen zur übergeordneten StmModuleInstantiation (Kardinalität 1 : n).
  • Abhängigkeit «overrides» (gestrichelte Linie): Explizite Übersteuerung des Modul-Defaults. Ist an einer spezifischen ActionList ein Wert konfiguriert, ersetzt dieser zwingend den Default-Wert der StmModuleInstantiation.
  • Effektive Werte:
    • ActionList1 → 300 (Default)
    • ActionList2 → 60 (Override)
    • ActionList3 → 300 (Default)
    • ActionList4 → 600 (Override)

3. Dynamisches Verhalten & Sequenzablauf

• Trigger: Ein interner Zustandswechsel, eine Trigger-Bedingung oder eine externe Anforderung (z. B. via StateClient oder RecoveryActionClient) stößt die Abarbeitung einer ActionList an.
• Timer-Initialisierung (SWS_SM_00667, SWS_SM_00668):
  1. SM prüft bei Ausführungsstart, ob an der konkreten ActionList ein maxActionListDuration definiert ist (SWS_SM_00667).
  2. Falls vorhanden (z. B. ActionList2 = 60, ActionList4 = 600), wird dieser Wert als Überwachungsintervall geladen.
  3. Falls nicht vorhanden (z. B. ActionList1, ActionList3), fällt SM auf StmModuleInstantiation.maxActionListDuration zurück (300, SWS_SM_00668).
  4. Ein asynchroner Monitortimer wird gestartet und die Liste der Aktionen abgearbeitet.
• Synchrone / Asynchrone Aktionsabarbeitung:
  • Einzelaktionen innerhalb der Liste können synchron oder asynchron sein (z. B. Warten auf Rückmeldung eines Service-Aufrufs via ara::com).
• Terminierung vs. Timeout (SWS_SM_00669):
  • Erfolgsfall: Schließen alle Aktionen der Liste vor Ablauf des effektiven Zeitfensters ab, wird der Timer gestoppt; der Zustandsübergang gilt als vollzogen.
  • Timeout-Verletzung (SWS_SM_00669): Erreicht der Timer den Schwellenwert vor Abschluss aller Aktionen, feuert das Timeout-Ereignis. SM bricht die weitere reguläre Abarbeitung ab, meldet einen Fehler (Logging, Meldung an Platform Health Management / PHM bzw. Dem) und leitet konfigurierte Recovery-/Eskalationsmaßnahmen ein.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Modellierung (Execution & State Management Manifest):
  • Entwickler müssen auf Ebene StmModuleInstantiation stets einen defensiven Baseline-Timeout vorgeben, um unüberwachte Endlosschleifen oder hängende IPC-Aufrufe bei unvollständig spezifizierten ActionList-Elementen abzufangen.
• Granulare Parametrierung:
  • Schnelle, rein interne Zustandswechsel (z. B. Setzen interner Flags, lokale Variablenzuweisungen) sollten via ActionList.maxActionListDuration restriktiv konfiguriert werden (wie ActionList2 mit kurzem Timeout), um Fehler frühzeitig zu isolieren.
  • Verteilte Aktionen mit potentiellen Latenzen (z. B. Herunterfahren externer Prozesse, synchrone Flash-/Persistenz-Vorgänge) erfordern einen gezielten Override nach oben (wie ActionList4), um Fehlauslösungen von Schutzmechanismen zu vermeiden.
• Fehlerbehandlungskonzept:
  • Der Timeout ist eine harte Deadline. Nachgeschaltete Applikationen und Plattformdienste dürfen sich nicht auf unvollständig ausgeführte Aktionslisten verlassen; das System muss für den Fall eines Timeouts transaktionale Sicherheit bzw. idempotente Rollback-/Notfall-Zustände vorsehen.