Figure 9.113: Interfaces for ECU Reset

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Schnittstellenspezifikation mit AUTOSAR-Adaptive-Stereotypen (AUTOSAR AP Metamodell-Erweiterung).
• Technischer Zweck: Spezifikation der Interprozess- und Framework-Schnittstelle zwischen dem daemon-basierten Plattform-Cluster Diagnostic Management (DM) und einer Adaptive Application (typischerweise State Management oder ein dedizierter System-/Reset-Handler) zur Abwicklung von Diagnose-Resets (UDS Service 0x11 ECUReset gemäß ISO 14229-1).
• Architektur-Kontext: AUTOSAR Adaptive Platform (R25-11), funktionale Schnittstellenabstraktion im Kontext von ara::diag.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten:
  • Adaptive Application («Component»): Applikationsprozess im POSIX User Space, der die anwendungsspezifische Reset-Logik vorhält und Hardware-/System-Zustände vor dem Neustart absichert.
  • Diagnostic Management daemon-based («aapFunctionalCluster», «Component»): Zentraler Plattform-Daemon, der UDS-Transportschichten (DoIP) terminiert, Diagnostic Sessions/Security Access verwaltet und UDS-Service-Requests dispatcht.
  • EcuResetRequest («aapPortInterface, aapPlatformExtension»): Plattform-Erweiterungs-Portinterface, das Lebenszyklus- und Callback-Methoden für Reset-Operationen kapselt.
• Schnittstellenmethoden & Stereotypen:
  • Synchron/Lifecycle (Applikation → Daemon):
    • + Offer(): Registriert den Reset-Handler der Applikation am Diagnostic Management Daemon.
    • + StopOffer(): Deregistriert den Handler; nachfolgende UDS 0x11-Anfragen werden vom Daemon abgelehnt.
  • «aapCallbackMethod» (Daemon → Applikation):
    • + RequestReset(): Prüft die Zulässigkeit des angeforderten Resets anhand applikativer Vorbedingungen.
    • + ExecuteReset(): Löst den tatsächlichen physischen bzw. logischen Neustart aus.
    • + EnableRapidShutdown(): Signalisiert den Übergang in den energiesparenden Schnellabschalt-Modus (UDS Subfunction rapidPowerDown).
• Beziehungen:
  • Adaptive Application → EcuResetRequest: Abhängigkeit über «use» und «aapRequiredPort». Die Applikation konsumiert das Interface zur Bereitstellung der Callbacks und zur Steuerung der Service-Verfügbarkeit.
  • Diagnostic Management daemon-based → EcuResetRequest: Realisierungsbeziehung (gestrichelte Linie mit geschlossener, nicht ausgefüllter Pfeilspitze). Der Daemon implementiert die Schnittstelleninfrastruktur und ruft die registrierten Callbacks auf.

3. Dynamisches Verhalten & Sequenzablauf

1. Service-Registrierung:
   • Nach dem Start bindet die Adaptive Application den Required Port und meldet ihre Bereitschaft über Offer() an den DM-Daemon.
2. UDS Service 0x11 Trigger:
   • Ein Diagnosetester sendet eine 0x11 <ResetType>-PDU via DoIP an das Fahrzeug/HPC.
   • Der DM-Daemon validiert Diagnostic Session, Security Level und Adressierung.
3. Validierungsphase (RequestReset):
   • Der Daemon triggert RequestReset() via IPC an der Applikation.
   • Die Applikation prüft lokale Sicherheitszustände (z. B. Fahrzeugstillstand, laufende Flash-/Schreibzyklen) und liefert kPositiveResponse oder einen UDS NRC (z. B. 0x22 ConditionsNotCorrect).
4. Quittierung & UDS-Timing:
   • Bei Freigabe sendet der Daemon die positive UDS-Antwort (0x51 <ResetType>) an den Tester, um das UDS-Timing (P2 / P2^* Timeout) einzuhalten.
5. Ausführungsphase (ExecuteReset / EnableRapidShutdown):
   • Unmittelbar nach Bestätigung der Tx-Übertragung der UDS-Antwort triggert der Daemon ExecuteReset() (bzw. EnableRapidShutdown()).
   • Die Applikation initiiert den geregelten Shutdown über das Execution Management (ara::exec / ara::sm) oder stößt den Hardware-Watchdog/PMIC-Reset an.
6. Deregistrierung:
   • Vor Termination ruft die Applikation StopOffer().

4. Normative Relevanz & Entwickler-Hinweise

• UDS-Protokollkonformität (ISO 14229-1): Die strikte Trennung zwischen RequestReset() und ExecuteReset() garantiert, dass der Reset erst erfolgt, nachdem die positive Response vollständig übertragen wurde. ExecuteReset() darf niemals synchron innerhalb von RequestReset() blockierend aufgerufen werden.
• Non-Blocking Callback Execution: Die Methoden RequestReset(), ExecuteReset() und EnableRapidShutdown() müssen reentrant bzw. asynchron ausgelegt sein (Rückgabe von ara::core::Future / Result-Typen im C++-Binding), um den IPC-Dispatcher des Daemons nicht zu blockieren.
• Interaktion mit State Management: Eine reguläre Adaptive Application darf selten direkt einen Kernel-Reboot (sys_reboot) initiieren. Die ExecuteReset()-Implementierung muss mit dem State Management (ara::sm) interagieren, um alle running Applications via Execution Management sauber in den Zielzustand zu überführen.
• ARXML-Modellierung: Im Software Component Description Manifest muss ein RPortPrototype mit Verweis auf das PortInterface EcuResetRequest konfiguriert werden; der DM-Daemon benötigt das korrespondierende Gegenstück zur Instanziierung des Kommunikationskanals.