Figure 9.102: Interfaces required by Diagnostic Management from State Management

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm / Schnittstellenspezifikation (AUTOSAR Adaptive Platform, Profil EXP_SWArchitecture).
• Funktionale Einordnung: Interaktion zwischen den Functional Clustern (FC) Diagnostic Management (DM) und State Management (SM) der AUTOSAR Adaptive Platform (ARA).
• Technischer Zweck: Das Diagnostic Management terminiert UDS-Dienste (ISO 14229-1), besitzt jedoch keine direkte Ausführungshoheit über das Gesamtsystem oder den Maschinenstatus. Für zustandsverändernde Rücksetzvorgänge und Rapid-Shutdown-Anforderungen delegiert DM die Aktionen an das State Management:
  • UDS Service 0x11 (ECUReset) sowie Rapid-Shutdown-Anforderungen → EcuResetRequest-Schnittstelle.

2. Komponenten, Entitäten & Schnittstellen

Entitäten (Functional Cluster)

• Diagnostic Management («aapFunctionalCluster» / im Diagramm «aapFunctionalClust...», daemon-based):
  • Verarbeitet Diagnose-Sessions und UDS-Nachrichten vom Tester.
  • Fungiert als Service-Consumer (Client-Rolle, oben im Diagramm platziert) und bindet die Schnittstelle über einen Required Port («aapRequiredPort») mit Abhängigkeit «use» an.
• State Management («aapFunctionalCluster» / im Diagramm «aapFunctionalClust...», daemon-based):
  • Verwaltet System-, Funktionsgruppen- und Maschinenzustände.
  • Fungiert als Service-Provider (Server-Rolle, unten im Diagramm platziert) und implementiert die Schnittstelle EcuResetRequest.

Schnittstellen («aapPortInterface, aapAPI»)

1. EcuResetRequest
   • Schnittstelle zur Einleitung von Rücksetzvorgängen und schnellem Herunterfahren (UDS 0x11).
   • Operationen:
     • EnableRapidShutdown(): Freigabe bzw. Triggern des schnellen Herunterfahrens bei Spannungsabfall oder diagnostischer Vorbereitung.
     • ExecuteReset(): Verbindlicher Befehl zur finalen Durchführung des Resets nach Vorbereitungsphase.
     • Offer() / StopOffer(): Lebenszyklus-Methoden zur Bereitstellung/Rücknahme der Service-Instanz über das Kommunikations-Framework (ara::com).
     • RequestReset(): Initiierung einer Rücksetzanforderung (z. B. hardReset, keyOffOnReset, softReset).

Beziehungen & Stereotypen

• Interface Realization (--▷ gestrichelt mit geschlossener, nicht gefüllter Pfeilspitze): State Management implementiert und exponiert das Service-Interface EcuResetRequest (Pfeil von unten nach oben zur Schnittstelle).
• Port Usage («use», «aapRequiredPort» gestrichelt mit offener Pfeilspitze): Diagnostic Management verlangt diesen Port als Abhängigkeit zur Laufzeit via IPC/Service-Broker (Pfeil von oben nach unten zur Schnittstelle).

3. Dynamisches Verhalten & Sequenzablauf

UDS Service 0x11 (ECUReset)

1. Tester-Trigger: Der externe Diagnosetester sendet eine UDS-Nachricht 0x11 [subFunction] an das Diagnostic Management.
2. Vorvalidierung: DM prüft Session-Berechtigung, Security Access und Parameter (NRC-Prüfung).
3. Reset-Anforderung: DM ruft EcuResetRequest::RequestReset() auf. Das State Management prüft interne Bedingungen (laufende Updates, Sicherheitszustände).
4. Positive Response (PR): Sofern das Protokoll ein Quittieren vor dem physikalischen Reset fordert, sendet DM die UDS-Antwort an den Tester.
5. Ausführung: DM ruft EcuResetRequest::ExecuteReset() auf. Das State Management initiiert über den Execution Management (EM) Daemon den kontrollierten Shutdown der Applikationen und triggert den Plattform-Neustart via OS/Hardware-Watchdog.

Rapid Shutdown

1. Trigger: DM erkennt eine Bedingung für schnelles Herunterfahren (z. B. diagnostischer Shutdown-Befehl oder Spannungsverlust).
2. Signal: DM ruft EcuResetRequest::EnableRapidShutdown() auf.
3. Zustandsübergang: SM versetzt das System ohne zeitaufwendiges Sichern nichtflüchtiger Daten in einen minimalen Standby- oder Power-Down-Modus.

4. Normative Relevanz & Entwickler-Hinweise

• Architekturtrennung: DM besitzt keine Berechtigung, System-Calls (z. B. reboot(), shutdown()) direkt auszuführen. Die gesamte Reaktivität auf Diagnosebefehle bezüglich des Maschinen- und Reset-Status muss über die SM-Schnittstelle EcuResetRequest geroutet werden.
• IPC / Middleware-Bindung: Da beide Funktionscluster als eigenständige Daemons (daemon-based) laufen, erfolgt die Port-Kopplung prozessübergreifend via IPC (ara::com-Binding). Das SM muss vor dem DM initialisiert sein und die Services via Offer() registriert haben, um ara::com::ServiceNotAvailable-Fehler im DM zu vermeiden.
• Asynchrone Entkopplung & Timeouts: Reset-Anforderungen müssen im State Management asynchron verarbeitet werden. Entwickler müssen sicherstellen, dass Rückmeldungen innerhalb der UDS-P2/P2*-Zeitschranken an DM zurückgeliefert werden, um unberechtigte NRC 0x78 (Response Pending) oder UDS-Timeouts zu verhindern.
• Manifest-Konfiguration: In den ARXML-Execution- und Service-Instance-Manifesten muss das Service-Interface EcuResetRequest als ProvidedServiceInstance (SM) und RequiredServiceInstance (DM) mit übereinstimmender Service-Contract-ID gemappt werden.