Figure 2: OS-Application State Machine

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Zustandsautomat (State Machine Diagram, Modell-Präfix stm OS Application State Machine).
• Architektur-Kontext: AUTOSAR Classic Platform, Schicht des Betriebssystems (AUTOSAR OS / BSW) im Kontext der Fehlerbehandlungs- und Isolationsarchitektur (Application Level Error Handling / Safety Partitioning gemäß Scalability Class 3 & 4 / SC3, SC4).
• Technischer Zweck: Spezifikation des deterministischen Laufzeit-Lebenszyklus einer OS-Application. Definiert die Zustände zur Kapselung von Software-Partitionen (Tasks, ISRs, Alarme, Schedule Tables) zwecks Laufzeitüberwachung, kontrolliertem Wiederanlauf (Application Restart) oder finaler Deaktivierung (Termination) im Fehlerfall zur Vermeidung von Gesamtsystem-Resets.

2. Komponenten, Entitäten & Schnittstellen

• Zustände (ObjectState / OS-Application Lifecycle):
  • Initial: Pseudozustand; Eintrittspunkt während der OS-Bootphase (StartOS()).
  • APPLICATION_ACCESSIBLE: Normalbetriebszustand. Alle zugewiesenen OS-Objekte sind aktivierbar; Lese- und Schreibzugriffe sowie Inter-OS-Application-Aufrufe (IOC / Cross-Core / Cross-Partition) sind autorisiert.
  • APPLICATION_RESTARTING: Quarantäne- und Reinitialisierungszustand. Reguläre Tasks/ISRs sind gestoppt; ausschließlich der dedizierte Restart-Task (OsRestartTask) wird ausgeführt. Zugriffe externer Applikationen werden blockiert.
  • APPLICATION_TERMINATED: Finaler Endzustand. Die Partition ist vollständig stillgelegt; alle zugehörigen OS-Objekte sind entladen bzw. dauerhaft inaktiv.
• Schnittstellen, Services & Events (Trigger):
  • Protection-Hook-Aktionen:
    • PRO_TERMINATEAPPL: Return-Wert des ProtectionHook nach einer Schutzverletzung (Memory Violation, Timing Violation); fordert das OS zur Terminierung ohne Neustart auf.
    • PRO_TERMINATEAPPL_RESTART: Return-Wert des ProtectionHook; fordert Terminierung aller regulären Tasks/ISRs und anschließenden Übergang in den Restart-Modus.
  • OS-APIs:
    • TerminateApplication(ApplicationType Application, RestartType RestartOption): OS-Kernel-Dienst zur synchronen Terminierung einer Ziel-Partition (AppID) oder der eigenen Partition (self) mit den Parametern NO_RESTART oder RESTART.
    • AllowAccess(void) (im Diagramm schematisch als AllowAccess(AppID) dargestellt): Systemaufruf, mit dem der Restart-Task dem OS signalisiert, dass die Reinitialisierung abgeschlossen ist und Zugriffe wieder freigegeben werden.

3. Dynamisches Verhalten & Sequenzablauf

1. Bootstrapping:
   • Nach Durchlauf der Boot-Sequenz und Abschluss von StartOS() wechselt jede konfigurierte OS-Application vom Pseudozustand Initial deterministisch in den Zustand APPLICATION_ACCESSIBLE.
2. Direkte Terminierung (Pfad APPLICATION_ACCESSIBLE → APPLICATION_TERMINATED):
   • Trigger: Asynchron über den ProtectionHook via Rückgabewert PRO_TERMINATEAPPL oder synchron über den API-Aufruf TerminateApplication(AppID, NO_RESTART).
   • Ablauf: Der OS-Kernel bricht alle aktiven Tasks und ISRs der Ziel-Applikation sofort ab, entzieht ihnen die Prozessorzeit, gibt reservierte OS-Ressourcen/Spinlocks frei und markiert die Partition als APPLICATION_TERMINATED.
3. Partition-Restart (Pfad APPLICATION_ACCESSIBLE → APPLICATION_RESTARTING):
   • Trigger: Rückgabewert PRO_TERMINATEAPPL_RESTART aus dem ProtectionHook oder expliziter API-Aufruf TerminateApplication(AppID, RESTART).
   • Ablauf: Alle regulären Tasks/ISRs werden gestoppt, anstehende Alarme/Aktivierungen gelöscht. Das OS aktiviert exklusiv den in der OS-Konfiguration hinterlegten OsRestartTask.
4. Wiederherstellung (Pfad APPLICATION_RESTARTING → APPLICATION_ACCESSIBLE):
   • Trigger: Synchroner Aufruf von AllowAccess() durch den ausgeführten OsRestartTask.
   • Ablauf: Das OS schaltet die Partition zurück in den Zustand APPLICATION_ACCESSIBLE. Externe Zugriffe und normale Task-Aktivierungen sind ab diesem Zeitpunkt wieder erlaubt.
5. Fehlgeschlagener Wiederanlauf (Pfad APPLICATION_RESTARTING → APPLICATION_TERMINATED):
   • Trigger: Synchroner Aufruf von TerminateApplication(self, NO_RESTART) durch den OsRestartTask (z. B. wenn eine Reinitialisierung der Hardware/Speicherbereiche scheitert) oder erneute Schutzverletzung während der Ausführung des Restart-Tasks.
   • Ablauf: Der Restart-Task wird beendet; die OS-Application wechselt endgültig in APPLICATION_TERMINATED.

4. Normative Relevanz & Entwickler-Hinweise

• OS-Konfiguration (OIL / ARXML):
  • Wird ein Zustandswechsel nach APPLICATION_RESTARTING vorgesehen, muss dem Container OsApplication zwingend ein OsRestartTask zugeordnet sein. Ein Fehlen führt bei Anforderung von RESTART zur Kernel-Panic oder zum Gesamtsystem-Shutdown (ShutdownOS).
• API-Fehlerverträge für SWCs & BSW:
  • Befindet sich eine Ziel-Applikation in APPLICATION_RESTARTING oder APPLICATION_TERMINATED, quittieren OS-Dienste (z. B. ActivateTask, SetEvent, GetAlarm) von außen den Zugriff zwingend mit E_OS_ACCESS.
  • Non-Trusted OS-Applications dürfen TerminateApplication normativ nur auf sich selbst anwenden (Application == self); ein Zugriff auf fremde Applikationen wird mit E_OS_ID oder E_OS_ACCESS abgewiesen.
• RTE- und Inter-Partition-Kopplung (IOC):
  • SWCs und Treiber dürfen während des Zustands APPLICATION_RESTARTING nicht blockierend auf Antworten der Partition warten.
  • RTE-Kommunikationskanäle müssen Timeouts und Rückfallstrategien (Invalidation Values, Init Values) implementieren, um zu verhindern, dass der Zustand APPLICATION_TERMINATED einer einzelnen SWC benachbarte Partitionen kaskadierend blockiert.
• Implementierungsanforderung an den Restart-Task:
  • Der Restart-Task muss mit Supervisor/Trusted-Rechten oder dedizierten MPU-Rechten operieren, um verunreinigte statische Variablen/Puffer der Partition zurückzusetzen, und muss deterministisch vor Erreichen von Watchdog-Grenzen AllowAccess() aufrufen.