Figure 5.3: Interfaces required by Diagnostic Management from State Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm (Component / Interface Diagram) im Metamodell der AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Spezifikation der standardisierten Inter-Cluster-Schnittstelle zwischen den funktionalen Clustern Diagnostic Management (DM) und State Management (SM).
• Funktionale Einordnung: In der Adaptive Platform besitzt der DM-Daemon keine direkte Berechtigung oder Funktionalität, um das Betriebssystem, den Hypervisor oder die Maschinen-Hardware neu zu starten. Steuergeräte-Resets (UDS Service 0x11 ECUReset) sowie Rapid-Shutdown-Abläufe erfordern koordinierte Zustandsübergänge (Herunterfahren von Prozessen, Aushängen von Dateisystemen, Maschinenstatuswechsel via Execution Management). Daher delegiert das DM Reset- und Shutdown-Anforderungen über das Service-Interface EcuResetRequest an das State Management.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Komponenten (Funktionale Cluster):
  • «aapFunctionalCluster» Diagnostic Management daemon-based:
    • Client / Konsument der Schnittstelle. Führt UDS-Protokollvalidierung, Session-/Security-Prüfungen und Event-Management aus.
    • Ausgestattet mit einem Required Port («aapRequiredPort»), markiert über die Verwendungsbeziehung «use».
  • «aapFunctionalCluster» State Management daemon-based:
    • Server / Provider der Schnittstelle. Orchestriert Function Groups, Machine States und System-Shutdowns.
    • Realisiert das Interface (gekennzeichnet durch den UML-Realization-Pfeil: gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze).
• Port-Interface & Operationen:
  • «aapPortInterface,aapAPI» EcuResetRequest:
    • Dual typisiert als Port-Interface im ARXML-Modell («aapPortInterface») und als standardisierte C++-Plattform-API («aapAPI»).
    • Methoden im Deklarationsumfang:
      • + RequestReset(): Meldet einen bevorstehenden Reset beim SM an (Mapping auf UDS-Subfunktionen wie HardReset 0x01, KeyOffOnReset 0x02, SoftReset 0x03).
      • + ExecuteReset(): Befiehlt dem SM die endgültige Ausführung des Resets nach erfolgreichem Versand der UDS-Positivantwort an den Tester.
      • + EnableRapidShutdown(): Aktiviert im SM den Schnellabschalt-Modus (UDS Subfunktion 0x04 enableRapidShutdown), um bei Zündungswechsel unkritische Nachlaufphasen zu überspringen.
      • + Offer(): Lifecycle-Methode der Service-Skeleton-Implementierung im SM zur Bereitstellung des IPC-/Service-Endpoints.
      • + StopOffer(): Lifecycle-Methode der Service-Skeleton-Implementierung zur De-Registrierung des Interfaces (z. B. bei kontrolliertem SM-Shutdown).
• Beziehungen & Abhängigkeiten:
  • Diagnostic Management → EcuResetRequest: «use» / «aapRequiredPort» (R-Port-Bindung).
  • State Management → EcuResetRequest: Realisierung / Bereitstellung (P-Port-Bindung / Service Skeleton).

3. Dynamisches Verhalten & Sequenzablauf

1. UDS-Request-Eingang:
   • Der externe Diagnosetester sendet einen UDS-Request Service 0x11 (ECUReset) über DoIP/UDS an den DM-Daemon.
2. Vorprüfung & Vorbereitung (RequestReset):
   • Das DM prüft aktive Session (Default vs. Non-Default) und Security-Level.
   • Bei Erfolg ruft das DM RequestReset() am EcuResetRequest-Interface des SM auf.
   • SM prüft maschinenweite Bedingungen (z. B. Fahrzeugstillstand, kritische Funktionszustände) und signalisiert die Freigabe.
3. Sonderbehandlung Rapid Shutdown (EnableRapidShutdown):
   • Bei Subfunktion 0x04 wird vorab EnableRapidShutdown() getriggert, woraufhin das SM entsprechende Flags für die nächste Transition in den Ruhezustand setzt.
4. Zweiphasige Entkopplung & UDS-Antwort:
   • Vor dem tatsächlichen Reset muss die positive UDS-Response (0x51 [subFunction]) zwingend vollständig über den Netzwerkstack an den Tester übertragen werden.
   • Das DM wartet auf das Sendebestätigungs-Event (Tx-Confirmation via DoIP/Transport Layer).
5. Reset-Trigger (ExecuteReset):
   • Nach gesicherter Übertragung ruft das DM ExecuteReset() auf.
   • Das SM übernimmt die Kontrolle, initiiert das geordnete Stoppen aller Applikationen via Execution Management (ara::exec) und leitet den Hardware-/Kernel-Neustart der Machine ein.
6. Fehler- & Abbruchpfade:
   • Verweigert das SM RequestReset() (z. B. wegen sicherheitskritischer Zustände), bricht das DM den Ablauf ab und antwortet mit NRC 0x22 (ConditionsNotCorrect).

4. Normative Relevanz & Entwickler-Hinweise

• Strikte Trennung von Diagnose- und Plattformlogik: Applikations- und BSW-Entwickler dürfen keine direkten System-Reboots (wie reboot() oder Kernel-Syscalls) aus dem Diagnosekontext ausführen. Sämtliche Reset-Aktionen müssen zwingend über den SM-Dienst aggregiert werden, um Inkonsistenzen in Dateisystemen, nicht-flüchtigen Speichern (ara::per) und Prozessen (ara::exec) zu verhindern.
• Race-Condition-Vermeidung: Die funktionale Aufteilung in RequestReset() und ExecuteReset() ist normativ bindend. Ein synchrones Durchstarten direkt bei Empfang der PDU führt zum Verlust der TCP/IP-Verbindung, bevor das ACK/die Diagnoseantwort das Steuergerät verlässt (Verletzung von ISO 14229-1).
• Service-Deployment & Manifeste:
  • Im Execution- und Service-Instance-Manifest muss die IPC-Verbindung zwischen dem P-Port des State Management und dem R-Port des Diagnostic Management deklariert und instanziiert sein.
  • Das SM muss Offer() vor dem Eintritt des DM in den betriebsbereiten Diagnosemodus aufgerufen haben; das DM muss auf das Vorhandensein des Proxies synchronisieren (FindService bzw. initiales Binding).