Figure 4.30: Modeling of DiagnosticDoIpActivationLinePortMapping to indicate the existence of a handler for the DoIP activation line

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Metamodell-Klassendiagramm (M2-Metamodell-Ausschnitt gemäß AUTOSAR Adaptive Platform, TPS Manifest Specification).
• Funktionale Einordnung & Zweck: Das Metamodell definiert die deklarative Anbindung eines anwendungsspezifischen DoIP-Aktivierungsleitungs-Handlers an den Diagnose-Stack (Diagnostic Management Daemon / DoIP-Daemon). Über DiagnosticDoIpActivationLinePortMapping wird im Execution-/Diagnostic-Manifest festgelegt, welcher ProcessDesign und welcher konkrete PPortPrototype eines Executables den Zustand der physischen oder logischen DoIP-Aktivierungsleitung (DoIP Activation Line gem. ISO 13400-2) bereitstellt.

2. Komponenten, Entitäten & Schnittstellen

Metaklassen & Stereotypen

• PortInterface («ARElement», «AtpBlueprint», «AtpBlueprintable», «AtpType»): Abstrakte Basisklasse aller AUTOSAR-Schnittstellen.
• DiagnosticPortInterface: Abstrakte Spezialisierung von PortInterface für die diagnosebezogene Service-Kommunikation.
• DiagnosticDoIPActivationLineInterface: Konkrete Schnittstellendefinition (specializes DiagnosticPortInterface) zur Signalisierung des Leitungsstatus (z. B. Pegelwechsel HIGH/LOW, Flankenerkennung oder Wake-Up-Trigger) an den DoIP-Stack.
• PPortPrototype (specializes AbstractProvidedPortPrototype): Repräsentiert den bereitstellenden Port an einer Software-Komponente bzw. einem Executable.
  • Assoziation: +providedInterface [0..1] mit Stereotyp «isOfType» und Constraint {redefines atpType}, typisiert auf PortInterface (hier konkret instanziiert als DiagnosticDoIPActivationLineInterface).
• Process (specializes AbstractExecutionContext): Repräsentiert die zur Laufzeit instanziierte Betriebssystem-Instanz.
  • Assoziation: +design [0..1] verweist auf das zugehörige ProcessDesign.
• ProcessDesign («ARElement»): Architektonischer Entwurf des Prozesses vor dem Deployment (bindet Executable und SWC-Modelle).
• DiagnosticMapping (specializes DiagnosticCommonElement): Basisklasse für Mapping-Elemente im Diagnose-Metamodell.
• DiagnosticSwMapping (specializes DiagnosticMapping): Verknüpft Diagnose-Funktionen mit Software-Konstrukten.
• AbstractDoIpPortMapping (specializes DiagnosticSwMapping): Abstrakte Zwischenklasse für DoIP-Port-Mappings.
  • Assoziation +process [0..1] zu ProcessDesign: Gekennzeichnet mit Stereotyp «atpSplitable» (erlaubt die Verteilung der ARXML-Definitionen über mehrere Beschreibungsdateien hinweg).
  • Referenz +pPortPrototypeInExecutable [0..1] zu PPortPrototype: Gekennzeichnet mit Stereotypen «atpUriDef,instanceRef» (modelliert eine formale Instanzreferenz auf den konkreten Port-Prototyp im Kontext des Executables).
• DiagnosticDoIpActivationLinePortMapping (specializes AbstractDoIpPortMapping): Konkretes Manifest-Element, das dem Generator und Daemon mitteilt, dass ein dedizierter Handler für die DoIP-Aktivierungsleitung existiert und wo dieser angebunden ist.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm beschreibt primär die statische Manifest-Konfiguration. Das daraus abgeleitete Laufzeitverhalten im Stack gestaltet sich wie folgt:

[Hardware Pin / GPIO] 
       │ 
       ▼ (Pegeländerung / Interrupt)
[Applikations-Handler] 
       │ 
       ▼ PPortPrototype (DiagnosticDoIPActivationLineInterface)
[ara::com IPC-Kanal]
       │ 
       ▼ (Service Event / Method Notification)
[DoIP Daemon / Diagnostic Management Daemon] (SWS_DM_00816)
       │
       ├─► Status == ACTIVE:
       │     └─► Öffnen des DoIP TCP/UDP-Listen-Sockets (Port 13400)
       │     └─► Senden von DoIP Vehicle Announcement Messages
       │
       └─► Status == INACTIVE:
             └─► Graceful Termination / Schließen aller TCP-Diagnosesitzungen
             └─► Deaktivieren des DoIP-Listeners zur Stromverbrauchsreduktion

• Trigger: Zustandsänderung der externen Hardware-Aktivierungsleitung (z. B. Pegel an Pin 8 des OBD-Steckers).
• Kommunikationspfad: Der Handler-Prozess erfasst den Pin-Status und publiziert das Update über den konfigurierten PPortPrototype (DiagnosticDoIPActivationLineInterface).
• Daemon-Reaktion: Der DoIP-Stack empfängt den Status asynchron über die ara::com-Servicebindung. Gemäß ISO 13400-2 wird der DoIP-Kommunikationskanal erst bei validiertem Aktivierungsstatus für externe Tester freigegeben.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Bedeutung (SWS_DM_00816): Die Existenz der DiagnosticDoIpActivationLinePortMapping-Instanz ist für den Codegenerator des Diagnostic-Stacks der normative Indikator, dass die DoIP-Aktivierungsleitung nicht plattformintern/statisch auf "immer aktiv" geschaltet ist, sondern zur Laufzeit über einen externen Handler-Prozess gesteuert wird.
• Manifest-Modellierung: Entwickler müssen sicherstellen, dass die Instanzreferenz pPortPrototypeInExecutable vollständig und konsistent bis zum PPortPrototype des Ziel-Executables im ExecutionManifest aufgelöst werden kann; fehlerhafte URIs führen zu Abbruchfehlern im Manifest-Compiler.
• Kardinalitäten & Restriktionen:
  • Multiplizität 0..1 bei pPortPrototypeInExecutable und process: Fehlt die Referenz trotz Vorhandenseins des Elements, ist das Modell semantisch ungültig.
  • Das Stereotyp «atpSplitable» an der Relation +process erlaubt OEMs und Zulieferern, das ProcessDesign und das Diagnose-Deployment (DiagnosticDoIpActivationLinePortMapping) in getrennten ARXML-Modulen versioniert einzupflegen.
• Applikations-API (ara::diag / ara::com): Der Entwickler des Aktivierungs-Handlers muss die Schnittstelle DiagnosticDoIPActivationLineInterface zwingend als Provider implementieren. Solange der Handler nach Systemstart keinen definierten Zustand meldet, verbleibt der DoIP-Stack im inaktiven Zustand (Sockets geschlossen, keine Tester-Verbindung möglich).