Figure 4.1: Master/Client example across Classic, Adaptive and Non-AUTOSAR platforms.

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Architektur- und Bereitstellungsdiagramm (Cross-Platform Deployment & Component Architecture Pattern).
• Technischer Zweck: Spezifikation eines verteilten System Health Management (SHM) unter Anwendung des Master/Client-Musters über heterogene Laufzeitumgebungen hinweg (AUTOSAR Adaptive Platform, AUTOSAR Classic Platform und Non-AUTOSAR/POSIX-Systeme).
• Funktionale Einordnung: Lokale Überwachungsmechanismen (AP: ara::phm, CP: WdgM) detektieren Funktions- und Ausführungsfehler rein plattformlokal. Das gezeigte SHM-Muster schließt die Lücke zur fahrzeugweiten Fehlerkorrelation, Systemdegradation und Funktionssicherheit (ASIL/ISO 26262) durch Aggregation dezentraler Health-Zustände in einer zentralen Schiedsstelle (SHM Master), die im gezeigten Entwurf auf der deterministischen Classic Platform alloziert ist.

2. Komponenten, Entitäten & Schnittstellen

Adaptive Platform (AP, links)

• SHM Client (Adaptive Application): Prozess im User Space, der lokale Überwachungsdaten aggregiert und das standardisierte Health-Info-Format für den Bus serialisiert.
• Adaptive Application: Zu überwachende funktionale Applikation (Prozess/Instanz).
• ARA (AUTOSAR Runtime for Adaptive Applications):
  • ara::phm (Platform Health Management): Führt lokale Überwachung der Adaptive Application durch (supervises: Alive-, Deadline- und Logical-Supervision über Checkpoints). Kommuniziert Health-Status-Events an den SHM Client.
  • ara::sm (State Management): Steuert Funktionsgruppen- und Plattformzustände (FunctionGroupState). Empfängt Recovery-/Degradationsbefehle vom SHM Client oder meldet geänderte Execution States.
  • ara::com (Communication Management): Service-orientierte Middleware (z. B. SOME/IP über IPC/Ethernet Binding), dient dem SHM Client als Ein-/Ausgangskanal für das Netzwerk.

Classic Platform (CP, Mitte)

• SHM Master (Classic Application Layer): Zentraler System-Health-Aggregator, implementiert als Application SW-C oberhalb der RTE.
• Application (Classic Application Layer): Zu überwachende Standard-SW-C.
• RTE (Real-Time Environment): Typisierte Schnittstellenschicht zur Entkopplung von BSW und SW-Cs.
• CP (Basic Software / BSW Layer):
  • WdgM (Watchdog Manager): Führt deterministische Programmablauf- und Alive-Überwachung der Application aus (supervises); meldet lokale Supervised-Entity-Status an den SHM Master und triggert den BswM.
  • BswM (Basic Software Mode Manager): Arbitriert ECU-/System-Modi; reagiert bidirektional auf Anforderungen des SHM Master zur lokalen Systemanpassung (z. B. Reset, Transition in Notlaufmodus).
  • COM (Communication Stack): BSW-Kommunikationstreiber/-schicht (Signal-/PDU-basiert via PduR, Can/EthIf); reicht aggregierte PDU-Nutzdaten via RTE an den SHM Master weiter.

Non-AUTOSAR Platform (rechts)

• SHM Client: Proprietärer Daemon / Middleware-Service auf Fremd-Betriebssystemen (z. B. Linux, QNX, RTOS).
• Non-AUTOSAR platform: Proprietärer Stack, angebunden über nicht-standardisierte interne OS-Mechanismen (gestrichelte Linien).

Netzwerk-Schnittstelle & Datenstruktur

• Physikalischer/Logischer Bus: Verbindet ara::com, COM und die Non-AUTOSAR-Schnittstelle (Ethernet/CAN FD).
• PDU-/Nachrichtenstruktur Health Info:
  • HealthIndicatorID: Identifikator der überwachten Funktionsentität/des Teilsystems.
  • Performance: Metrik zur Ausführungszeit, Latenz oder CPU-/Budget-Nutzung.
  • Reliability: Fehlerraten, Checkpoint-Verletzungszähler, Safety-/Plausibilitätsindikatoren.
  • SubsystemState: Diskreter Zustand des Subsystems (z. B. OK, DEGRADED, CRITICAL_FAULT).

3. Dynamisches Verhalten & Sequenzablauf

1. Lokale Fehlererkennung & Überwachung:
   • AP: Adaptive Application meldet Checkpoints an ara::phm. Bei Verletzungen (Timing-/Sequenzfehler) benachrichtigt ara::phm den SHM Client.
   • CP: Application meldet Checkpoints an WdgM. Bei Statuswechsel (WDGM_GLOBAL_STATUS_DEGRADED/STOPPED) erfolgt Meldung an den lokalen SHM Master und BswM.
   • Non-AUTOSAR: Plattforminterne Monitore setzen Statusflags im dortigen SHM Client.
2. Health-Info-Propagation (asynchron / zyklisch):
   • Die SHM Clients (AP & Non-AUTOSAR) verpacken das Tupel <HealthIndicatorID, Performance, Reliability, SubsystemState>.
   • Versand über das Netzwerk via ara::com bzw. Non-AUTOSAR-Stack in Richtung CP.
3. Zentrale Korrelation im Master:
   • Das CP-Modul COM nimmt die PDU/Service-Instanz an und routet die Daten via RTE an den SHM Master.
   • SHM Master korreliert externe Health-Events mit den lokalen WdgM-Meldungen und entscheidet über übergeordnete Notlaufstrategien.
4. Koordinierte Degradation & Recovery:
   • Lokal: SHM Master fordert via RTE beim BswM Moduswechsel an (BswM_RequestMode).
   • Remote: SHM Master sendet Degradationsanweisungen über COM zurück an den SHM Client der AP; dieser triggert ara::sm zur Umschaltung von FunctionGroupStates (z. B. gezieltes Beenden oder Reinitialisieren fehlerhafter Prozesse).

4. Normative Relevanz & Entwickler-Hinweise

• Status in der Spezifikation: Als Bestandteil von AUTOSAR_AP_EXP_PlatformDesign besitzt das Diagramm erläuternden (explanatory) Charakter. Es definiert kein einzelnes BSW-/ARA-Modul, sondern das standardisierte Integrationsmuster für fahrzeugweites Health Management.
• Schnittstellenverträge (API-Design):
  • AP-Entwickler: Der SHM Client muss standardisierte C++-APIs konsumieren: Schnittstellen zu ara::phm zur Überwachungsauswertung, ara::sm (Field-/Method-Interfaces für State Transitions) sowie das Service-Interface zu ara::com (generierte Skeleton/Proxy-Klassen für Health Info).
  • CP-Entwickler: Der SHM Master erfordert die Definition von Software-Ports im ARXML: Client-Server- bzw. Sender-Receiver-Interfaces für RTE-Verbindungen zu BswM (Modenanforderung) und WdgM (Statusübernahme) sowie ISignal-/PDU-Mapping im COM-Stack.
• Netzwerk- und Datentransformation:
  • Bei Anbindung von Adaptive Platform (ara::com, meist service-orientiert/SOME/IP) an Classic Platform (COM, signal- oder PDU-orientiert) ist entweder ein SOME/IP-fähiger CP-Stack (SoAd, Sd, SomeIpXf) oder ein Gateway-Knoten zwingend erforderlich.
• Safety & Echtzeit (FTTI):
  • Die Latenz des Übertragungspfades (ara::phm → SHM Client → ara::com → Bus → COM → SHM Master) muss strikt gegen die Fault Tolerant Time Interval (FTTI) des Gesamtsystems gerechnet werden. E2E-Protection (End-to-End Profile) auf der Health Info-PDU ist für sicherheitsrelevante Funktionen (ASIL B–D) verpflichtend.