Figure 9.74: D-PDU-API Interfaces

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponentendiagramm mit Schnittstellenrealisierung und Nutzungsabhängigkeit (Interface Realization & Usage Dependency).
• Technischer Zweck: Spezifikation der Bereitstellung und Konsumierung der ISO 22900-2-konformen D-PDU-API (Diagnostic Protocol Data Unit API) innerhalb der AUTOSAR Adaptive Platform (AP, R23-11).
• Funktionale Einordnung: Entkopplung der Flashing-Logik von den physikalischen Bus- und Transportprotokollen. Der Functional Cluster Update and Configuration Management (UCM) stellt die D-PDU-API bereit, damit anwendungsspezifische Adapter (Flashing Adapter) diagnostische PDUs zur Reprogrammierung von sekundären Steuergeräten (Secondary ECUs) über Busnetzwerke (z. B. CAN, LIN, DoIP/Ethernet) absetzen können.

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application (UML-Komponente):
  • Ausführbare Anwendungsentität (POSIX-Prozess) im User-Space der Adaptive Platform.
  • Beinhaltet die Subkomponente Flashing Adapter, welche die fahrzeug- oder herstellerspezifische Update-Sequenz (Bootloader-Kommunikation, Speicherlöschung, Transfer von Flash-Blöcken, Checksummen-Verifikation) kapselt.
• «aapAPI,aapNativeInterface» D-PDU API (UML-Interface):
  • «aapAPI»: Kennzeichnung als standardisierte Schnittstelle der AUTOSAR Adaptive Platform.
  • «aapNativeInterface»: C/C++-basierte native Programmierschnittstelle gemäß ISO 22900-2 / AUTOSAR D-PDU-API-Spezifikation (im Gegensatz zu dienstorientierten ara::com-Proxies/Skeletons).
• «aapFunctionalCluster» Update and Configuration Management (UML-Komponente):
  • Plattform-Kernbaustein zur Verwaltung von Software-Paketen, Rollbacks und ECU-Updates.
  • Realisierungsmuster: daemon-based (Ausführung als autonomer Hintergrund-Dienst/System-Daemon).
  • Kapselt die interne Subkomponente D-PDU API zur Protokollabstraktion und PDU-Verwaltung.
• Beziehungen:
  • Interface Realization (---▷): Das UCM (bzw. dessen interne D-PDU API-Komponente) implementiert die native Schnittstelle «aapAPI,aapNativeInterface» D-PDU API.
  • Usage Dependency (- - > «use»): Die Adaptive Application bzw. der Flashing Adapter greift konsumierend auf die D-PDU API zu.

3. Dynamisches Verhalten & Sequenzablauf

• Interaktionsmodell: Lokale Interprozesskommunikation (IPC) zwischen dem Application-Prozess und dem UCM-Daemon über eine systemnative Client-Bibliothek (Wrapper/Stub).
• Ablauf-Pipeline bei Reprogrammierung:
  1. Session-Initialisierung: Flashing Adapter ruft D-PDU-Basisfunktionen auf (PDUConstruct, PDUConnect, PDUIoCtl), um logische Kommunikationskanäle (ComLogicalLink) zu den Ziel-ECUs zu öffnen.
  2. PDU-Transfer (Request/Response): Asynchrone PDU-Übertragung (PDUSend, PDUReceive) von Diagnosenachrichten (z. B. UDS RequestDownload, TransferData, RequestTransferExit).
  3. Event- & Buffer-Handling: Asynchrone Callback-Verarbeitung für TX-Confirmations, RX-Indications sowie PDU-Buffer-Management und Timeout-Überwachung.
  4. Terminierung: Geordneter Verbindungs- und Ressourcenabbau (PDUDisconnect, PDUDestruct) nach Abschluss oder Abbruch der Flash-Sequenz.

4. Normative Relevanz & Entwickler-Hinweise

• Schnittstellen-Paradigma: Entwickler von Flashing-Adaptern binden direkt gegen die native C++-API der D-PDU-Spezifikation. Es erfolgt kein generierter ara::com-Code-Stack für diese Interaktion.
• Prozess- & Rechtemodell:
  • Da UCM als Daemon läuft und Zugriff auf raw-nahe Netzwerkressourcen (Sockets, Bus-Controller) gewährt, unterliegt die IPC-Kommunikation restriktiven Berechtigungsprüfungen (Identity and Access Management / IAM, POSIX Capabilities, SELinux/AppArmor-Policies).
  • Die Adaptive Application muss im Execution Manifest mit den erforderlichen Zugriffsrechten auf die UCM-D-PDU-Endpunkte deklariert sein.
• Portabilität: Der Flashing Adapter bleibt transportunabhängig; das Mapping auf DoIP-, CAN- oder FlexRay-Transceiver erfolgt deklarativ in den Bereitstellungs- und Netzwerkbeschreibungen des UCM-Stacks.