Figure 9.91: 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, die Netzwerk-Stacks oder den Maschinenstatus. Für zustandsverändernde Diagnose-Services delegiert DM die Aktionen an das State Management:
  • UDS Service 0x28 (CommunicationControl) → CommunicationControl-Schnittstelle.
  • UDS Service 0x11 (ECUReset) sowie Rapid-Shutdown-Anforderungen → EcuResetRequest-Schnittstelle.

2. Komponenten, Entitäten & Schnittstellen

Entitäten (Functional Cluster)

• State Management («aapFunctionalCluster», daemon-based):
  • Stellt Systemzustände, Funktionsgruppen (FunctionGroupState) und Netzwerkressourcen bereit.
  • Fungiert als Service-Provider (Server-Rolle) für die Ports CommunicationControl und EcuResetRequest.
• Diagnostic Management («aapFunctionalCluster», daemon-based):
  • Verarbeitet Diagnose-Sessions und UDS-Nachrichten vom Tester.
  • Fungiert als Service-Consumer (Client-Rolle) und bindet die Schnittstellen über Required Ports («aapRequiredPort») mit Abhängigkeit «use» an.

Schnittstellen («aapPortInterface, aapAPI»)

1. CommunicationControl
   • Schnittstelle zur Beeinflussung von Übertragungs- und Empfangsmodi für Kommunikationskanäle (UDS 0x28).
   • Operationen:
     • CommCtrlRequest(): Anforderung zur Aktivierung/Deaktivierung spezifischer Kommunikationspfade (z. B. Normal Communication, Diagnostic Communication).
     • Offer() / StopOffer(): Lebenszyklus-Methoden zur Bereitstellung/Rücknahme der Service-Instanz über das zugrundeliegende Kommunikations-Framework (ara::com).
2. EcuResetRequest
   • Schnittstelle zur Einleitung von Rücksetzvorgängen und schnellem Herunterfahren (UDS 0x11).
   • Operationen:
     • RequestReset(): Initiierung einer Rücksetzanforderung (z. B. hardReset, keyOffOnReset, softReset).
     • ExecuteReset(): Verbindlicher Befehl zur finalen Durchführung des Resets nach Vorbereitungsphase.
     • EnableRapidShutdown(): Freigabe bzw. Triggern des schnellen Herunterfahrens bei Spannungsabfall oder diagnostischer Vorbereitung.
     • Offer() / StopOffer(): Service-Offering-Methoden der Server-Instanz.

Beziehungen & Stereotypen

• Interface Realization (--▷ gestrichelt mit geschlossener, nicht gefüllter Pfeilspitze): State Management implementiert und exponiert beide Service-Interfaces.
• Port Usage («use», «aapRequiredPort» gestrichelt mit offener Pfeilspitze): Diagnostic Management verlangt diese Ports als Abhängigkeit zur Laufzeit via IPC/Service-Broker.

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.

UDS Service 0x28 (CommunicationControl)

1. Tester-Trigger: Der Tester fordert das Umschalten von Kommunikationsmodi an (z. B. disableRxAndTx).
2. Kanalumschaltung: DM ruft CommunicationControl::CommCtrlRequest() am State Management auf.
3. Netzwerksteuerung: SM interagiert mit Network Management (NM) / Communication Management (ara::com), um PDU-/Paketfilter bzw. Socket-Zustände für die betroffenen Schnittstellen umzuschalten.
4. Abschluss: Nach Bestätigung durch SM quittiert DM die Diagnoseanfrage positiv an den Tester.

4. Normative Relevanz & Entwickler-Hinweise

• Architekturtrennung: DM besitzt keine Berechtigung, System-Calls (z. B. reboot(), shutdown()) oder Socket-Filter direkt auszuführen. Die gesamte Reaktivität auf Diagnosebefehle bezüglich Maschinenstatus muss über SM-Standardports 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- und Kommunikationsumschaltungen müssen im State Management asynchron verarbeitet werden. Entwickler müssen sicherstellen, dass die 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 müssen die Service-Interfaces CommunicationControl und EcuResetRequest als ProvidedServiceInstance (SM) und RequiredServiceInstance (DM) mit übereinstimmender Service-Contract-ID gemappt werden.