Figure 9.4: StartupHook sequence chart The above sequence shows the flow of control during the startup of the OS. Like in OSEK OS the user calls the StartOS() service to start the OS. During the startup the startup hooks are called in the above order. The rest of the startup sequence is identical to the defined behaviour of OSEK OS.

1. Diagrammtyp & Architektur-Kontext

UML 2.x Sequenzdiagramm (sd Interactions) im Architektur-Kontext der AUTOSAR Classic Platform, Basic Software (BSW), System Services / Operating System (AUTOSAR OS gemäß AUTOSAR_SWS_OS). Das Diagramm spezifiziert den zeitlichen und hierarchischen Kontrollfluss der Betriebssystem-Hochlaufphase nach dem initialen Aufruf von StartOS() bis zum Eintritt in den regulären Betriebszustand (Normal Operation). Im Fokus steht die normative Aufrufreihenfolge von globalen, systemweiten Startup-Hooks im Vergleich zu anwendungsspezifischen Startup-Hooks für logisch partitionierte OS-Applications (OS-Appl. <App>).

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert zwei primäre Lebenslinien sowie einen initialen Pseudozustand:

• Initial: Startknoten / Kontrollflussursprung außerhalb des aktiven OS-Schedulings (Pre-OS-Kontext, typischerweise main() bzw. ECU State Manager EcuM).
• operating system: Kernel des AUTOSAR-Betriebssystems mit durchgehender Aktivierungsleiste über die gesamte Hochlaufphase.
• OS-Appl. <App>: Generische OS-Application-Entität (logische Partition/Schutzdomäne für Tasks, ISRs und Hooks).

Zustands- und Kontrollflusselemente:

• Zustandsinvariante / Statusbalken Startup (Initialisierungsphase des OS-Kernels) und Normal Operation (regulärer Scheduler-Betrieb).
• Synchroner Aufruf StartOS(<Mode>) mit Übergabe des Anwendungsmodus (AppModeType).
• Kombiniertes Fragment alt mit Guard-Bedingung [system-/application-specific Startup Hook are configured].
• Synchroner Selbstaufruf StartupHook auf der Lebenslinie des operating system.
• Synchroner Aufruf StartupHook_<App> vom operating system an OS-Appl. <App> inklusive gestricheltem Return-Pfeil nach Beendigung.

3. Dynamisches Verhalten & Sequenzablauf

Der dynamische Ablauf gliedert sich in folgende Sequenzschritte:

1. Der Pre-OS-Kontext (Initial) initiiert den Betriebssystemstart über den synchronen API-Aufruf StartOS(<Mode>) an das operating system.
2. Das Betriebssystem wechselt in den Zustand Startup und initialisiert interne Datenstrukturen, Interrupt-Controller und Hardware-Timer.
3. Im kombinierten Fragment alt wird geprüft, ob Startup-Hooks konfiguriert sind:
   • Ist ein globaler Startup-Hook konfiguriert, führt das Betriebssystem zuerst einen internen synchronen Selbstaufruf StartupHook im privilegierten Kernel-Modus aus.
   • Nach Rückkehr des globalen Hooks ruft das Betriebssystem sequenziell den anwendungsspezifischen Hook StartupHook_<App> der jeweiligen OS-Application auf.
   • Der Kontrollfluss verbleibt für die Dauer der Hook-Ausführung in der Partition OS-Appl. <App> und kehrt anschließend synchron zum Betriebssystem zurück.
4. Nach Abschluss aller konfigurierten Hooks verlässt das Betriebssystem die Startup-Phase und tritt in den Zustand Normal Operation über, womit die Task-Aktivierung und das präemptive/nicht-präemptive Scheduling beginnen.

4. Normative Relevanz & Entwickler-Hinweise

Aus der Sequenz ergeben sich wesentliche normative Vorgaben für Implementierung und Systemintegration:

• Verbindliche Kaskadierung: Der globale StartupHook() besitzt strikte Ausführungspriorität vor allen anwendungsspezifischen StartupHook_<App>()-Aufrufen. Globale Hardware- und BSW-Initialisierungen können somit vor anwendungsspezifischen Vorbereitungen abgeschlossen werden.
• Ausführungskontext: StartupHook läuft im privilegierten Systemmodus ohne Partitionsbeschränkung. StartupHook_<App> wird im geschützten Kontext der zugeordneten OS-Application ausgeführt (relevant für Speicherschutz SC3/SC4 und Timing Protection).
• API-Restriktionen: Während der Zustände Startup und innerhalb der Hooks sind gemäß AUTOSAR OS-Spezifikation nur stark eingeschränkte OS-Dienste zugelassen (keine blockierenden Aufrufe, kein Erzwingen von Taskwechseln oder Dispatching).
• OSEK-Konformität: StartOS() kehrt im Normalbetrieb nicht zum Aufrufer zurück. Der Übergang nach Normal Operation übergibt die Kontrolle dauerhaft an den Dispatcher/Scheduler des Betriebssystems.
• Optionalität: Die Guard-Bedingung kennzeichnet, dass beide Hook-Typen reine Konfigurationsoptionen (OsStartupHook, OsApplicationHooks/OsAppStartupHook) im BSW-OS-Modell darstellen.