Figure 4.23: Modeling of the DiagnosticSovdBulkDataPortMapping

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Ausschnitt (M2-Ebene) aus der AUTOSAR Adaptive Platform Spezifikation (AUTOSAR_AP_TPS_ManifestSpecification, R23-11).
• Technischer Zweck: Deklarative Verknüpfung (Deployment-Mapping) zwischen einer SOVD-Massen-Dateninstanz (Diagnostic SOVD Bulk Data) und dem bereitstellenden Software-Port (PPortPrototype) einer Applikation innerhalb eines spezifischen Ausführungskontextes (ProcessDesign / Process).
• Funktionale Einordnung: Kernbestandteil der Service-Oriented Vehicle Diagnostics (SOVD) Integration in der Adaptive Platform (AP). Es ermöglicht dem diagnostischen Plattform-Dämon (ARA Diagnostic Management / SOVD-Server), eingehende REST/HTTP-Anfragen für Bulk Data Transfers (z. B. Crash-Recorder-Daten, Traces, Core-Dumps, Logging-Archive) direkt an die verantwortliche Adaptive Application zu routen.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Klassenhierarchien

1. Mapping-Domäne (Mitte & Rechts unten):
   • DiagnosticSovdBulkDataPortMapping: Konkrete Mapping-Klasse zur Verknüpfung von Diagnose-Serviceinstanz und Applikations-Port. Erbt transitiv: $$\text{DiagnosticSovdBulkDataPortMapping} \xrightarrow{\text{erbt}} \text{DiagnosticSwMapping} \xrightarrow{\text{erbt}} \text{DiagnosticMapping} \xrightarrow{\text{erbt}} \text{DiagnosticCommonElement} \xrightarrow{\text{erbt}} \text{ARElement}$$
   • Assoziationen des Mappings:
     • +serviceInstance (Kardinalität 0..1): Ziel ist DiagnosticSovdBulkData.
     • +pPortPrototypeInExecutable (Kardinalität 0..1): Ziel ist PPortPrototype. Stereotypen: «instanceRef,atpUriDef» (formalisiert den Pfad zum Port im Executable-Kontext).
     • +process (Kardinalität 0..1): Ziel ist ProcessDesign. Stereotyp: «atpSplitable» (erlaubt Verteilung auf mehrere ARXML-Dateien).
2. SOVD-Serviceinstanz-Hierarchie (Mitte oben):
   • DiagnosticCommonElement (ARElement): Basisklasse diagnostischer Metamodellelemente.
   • DiagnosticSovdServiceInstance: Spezialisierung von DiagnosticCommonElement für SOVD-Dienste.
   • DiagnosticSovdBulkData: Konkrete Ausprägung einer SOVD-Massen-Dateninstanz (adressierbar über die SOVD-API).
3. Software-Port- & Interface-Hierarchie (Links):
   • PortInterface (ARElement, AtpBlueprint, AtpBlueprintable, AtpType): Generische Schnittstellen-Definition.
   • DiagnosticPortInterface → DiagnosticSovdPortInterface → DiagnosticSovdBulkDataInterface: Konkretes Schnittstellenmodell für Bulk-Data-Operationen.
   • AbstractProvidedPortPrototype / PPortPrototype: Bereitstellender Port der Applikation.
     • Relation +providedInterface (0..1, {redefines atpType}, Stereotyp «isOfType»): Typisiert den PPortPrototype durch das DiagnosticSovdBulkDataInterface.
4. Prozesskontext (Rechts):
   • ProcessDesign (ARElement): Repräsentiert das funktionale Design eines Prozesses auf Modellierungsebene.
   • Process (AbstractExecutionContext): Konkrete Instanz des Prozesses auf OS-Ebene; referenziert ProcessDesign über +design (0..1).

3. Dynamisches Verhalten & Sequenzablauf

Als statisches M2-Metamodell definiert das Diagramm die Konfigurationsbasis für folgende Laufzeitabläufe:

1. Service-Registrierung & Discovery: Beim Systemstart liest der AP Diagnostic / SOVD-Stack das Manifest (DiagnosticSovdBulkDataPortMapping), identifiziert den registrierten PPortPrototype via IPC/Skeleton und exponiert den zugehörigen SOVD-Bulk-Data-URI-Pfad (z. B. /sovd/v1/bulkdata/...).
2. Bulk Data Request (SOVD-Client → Server): Ein externer Client fordert Massendaten per HTTP/REST GET/POST an.
3. Plattform-Routing: Der SOVD-Daemon löst über das Mapping (serviceInstance ↔ pPortPrototypeInExecutable) den Zielprozess auf.
4. Applikations-Aufruf via ARA: Der Daemon delegiert das Auslesen/Schreiben über das DiagnosticSovdBulkDataInterface asynchron an die Applikation (z. B. via Stream-Chunking oder Paging).
5. Fehlerbehandlung: Bricht der Transfer ab oder liefert die Applikation einen Fehlercode, transformiert der SOVD-Dämon diesen in den standardisierten SOVD-HTTP-Statuscode (z. B. 404 Not Found, 500 Internal Error).

4. Normative Relevanz & Entwickler-Hinweise

• Normative Zuordnung: Erfüllt die Anforderungen RS_MANI_00005 (Standardisiertes Diagnostic Manifest) und RS_MANI_00061 (SOVD-Unterstützung im AP-Manifest).
• Manifest-Erstellung (ARXML):
  • Entwickler müssen für jede bereitzustellende Bulk-Data-Ressource zwingend eine Instanz von DiagnosticSovdBulkData deklarieren und diese per DiagnosticSovdBulkDataPortMapping dem entsprechenden PPortPrototype zuordnen.
  • Das Stereotyp «atpSplitable» an +process erlaubt es Software-Lieferanten, das Software-Design (ProcessDesign, PPortPrototype) unabhängig vom späteren Integrations- und Deployment-Manifest des OEMs (DiagnosticSovdBulkDataPortMapping, Process) zu versionieren.
• Applikations- & Stack-Implementierung (ara::diag / SOVD):
  • Die Applikation implementiert das vom Port-Interface generierte Skeleton für DiagnosticSovdBulkDataInterface.
  • Das Port-Mapping fordert zwingend einen PPortPrototype (Provide-Only); Bulk Data wird von der Applikation für den Diagnosestack ausschließlich bereitgestellt (Download) bzw. entgegengenommen (Upload-Handler).