Figure 6.7: DDS Service Interface Deployment

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (Ausschnitt des AUTOSAR Adaptive Platform Metamodells / Manifest-Modellierung).
• Technischer Zweck: Spezifikation des protokollspezifischen Netzwerk-Deployments für Service-Schnittstellen (ServiceInterface) auf Basis der Data Distribution Service (DDS) Middleware innerhalb von ara::com.
• Funktionale Einordnung: Definiert die Zuordnung abstrakter Service-Elemente (Events, Methods, Fields) zu konkreten DDS-Netzwerk-Artefakten (DDS Topics, Topic-Namen, Transportprotokolle) sowie den zugehörigen DDS-Security-Zugriffsregeln (DdsTopicAccessRule) gemäß OMG DDS-Security-Spezifikation.

2. Komponenten, Entitäten & Schnittstellen

Metamodell-Klassen & Attribute

• ServiceInterfaceDeployment (abstrakt, Basis: UploadableDesignElement):
  • Generisches Basiselement des Service-Deployments.
  • Hält Kompositionen zu generischen Event- und Field-Deployments, annotiert mit den Stereotypen «atpVariation,atpSplitable».
• DdsServiceInterfaceDeployment (Spezialisierung von ServiceInterfaceDeployment):
  • Spezifisches Deployment eines Services auf DDS.
  • Attribute:
    • fieldReplyTopicName: String [0..1]: Topic-Name für Antworten auf Field-Operationen (Get/Set-Replies).
    • fieldRequestTopicName: String [0..1]: Topic-Name für Anfragen auf Field-Operationen (Get/Set-Requests).
    • methodReplyTopicName: String [0..1]: Topic-Name für RPC-Rückgabewerte (Method Replies via DDS-RPC / Request-Reply Pattern).
    • methodRequestTopicName: String [0..1]: Topic-Name für RPC-Aufrufe (Method Requests).
    • serviceInterfaceId: String [0..1]: Eindeutige Kennung des Service-Interface im DDS-Domain-Kontext.
    • transportProtocol: String [0..*]: Zulässige Transportmechanismen (z. B. UDPv4, UDPv6, Shared Memory).
• ServiceEventDeployment (abstrakt, Basis: Identifiable):
  • Generisches Deployment für Service-Events.
• DdsEventDeployment (Spezialisierung von ServiceEventDeployment):
  • Bildet ein Service-Event auf ein DDS-Topic ab.
  • Attribute:
    • topicName: String [0..1]: Name des DDS-Topics für das Pub/Sub-Event.
    • transportProtocol: String [0..*]: Transportbindung für das Event.
• ServiceFieldDeployment (abstrakt, Basis: Identifiable):
  • Generisches Deployment für Service-Fields.
• DdsFieldDeployment (Spezialisierung von ServiceFieldDeployment):
  • Spezifisches DDS-Deployment für Fields.
  • Besitzt eine gerichtete Komposition +notifier [0..1] zu DdsEventDeployment (Realisation des Field-Notifiers über ein DDS-Event-Topic).
• DdsTopicAccessRule (Basis: UploadableDesignElement):
  • Sicherheitsrichtlinie für Topic-Zugriffskontrolle und Verschlüsselung gemäß DDS Security (DDS-SEC).
  • Attribute:
    • dataProtectionKind: DdsProtectionKindEnum [0..1]: Sicherheitsstufe für Nutzdaten (Payload).
    • enableDiscoveryProtection: Boolean [0..1]: Absicherung der Endpoint-Discovery (SPDP/SEDP).
    • enableLivelinessProtection: Boolean [0..1]: Kryptografische Absicherung von Liveliness-Nachrichten.
    • enableReadAccessControl: Boolean [0..1]: Erzwingt Autorisierung für DataReader (Subscriber).
    • enableWriteAccessControl: Boolean [0..1]: Erzwingt Autorisierung für DataWriter (Publisher).
    • metadataProtectionKind: DdsProtectionKindEnum [0..1]: Schutzstufe für Metadaten/RTPS-Submessages.
• DdsProtectionKindEnum («enumeration»):
  • none: Keine Integritätsprüfung oder Verschlüsselung.

3. Dynamisches Verhalten & Sequenzablauf

Obgleich es sich um ein statisches Metamodell handelt, steuern diese Instanzen das Laufzeitverhalten des ara::com-DDS-Bindings:

• Event-Kommunikation (Pub/Sub):
  • Senden eines Events instanziiert einen DDS DataWriter auf dem konfigurierten topicName (DdsEventDeployment).
  • Abonnenten erzeugen einen DDS DataReader. Ist eventTopicAccessRule definiert, prüft das DDS-Security-Plugin beim Discovery-Handshake die Berechtigungen (enableReadAccessControl / enableWriteAccessControl) und wendet dataProtectionKind (Signatur/Verschlüsselung) an.
• Methodenaufrufe (RPC via DDS):
  • Asynchroner Request/Reply-Kanal: Client sendet Request-Sample über methodRequestTopicName.
  • Server verarbeitet den Call und sendet Response über methodReplyTopicName mit Korrelations-ID.
  • Autorisierung und Schutz werden zentral über methodTopicsAccessRule parametrisiert.
• Field-Operationen (Get/Set/Notifier):
  • Status-Updates laufen asynchron über den referenzierten Notifier (+notifier -> DdsEventDeployment).
  • Direkte Lese-/Schreibzugriffe (Getter/Setter) nutzen das über fieldRequestTopicName und fieldReplyTopicName aufgespannte RPC-Muster, gesichert durch fieldTopicsAccessRule.

4. Normative Relevanz & Entwickler-Hinweise

• Metamodell-Einbindung & Variantenmanagement: ServiceInterfaceDeployment und DdsTopicAccessRule erben von UploadableDesignElement statt von UploadablePackageElement. Die Kompositionsbeziehungen +eventDeployment und +fieldDeployment sind mit «atpVariation,atpSplitable» annotiert, was die Aufteilung über mehrere ARXML-Dateien (splitable) sowie die Steuerung über AUTOSAR-Varianzbedingungen (variation) erlaubt.
• Kardinalitäten und Validierungsregeln:
  • transportProtocol [0..*] erlaubt die Bindung an mehrere Protokolle (z. B. UDPv4, UDPv6 oder Shared Memory). Fehlt die Angabe, greift der Plattform-Default.
  • Topic-Namen (topicName, methodRequestTopicName, methodReplyTopicName, fieldRequestTopicName, fieldReplyTopicName) sind optional [0..1]. Bei Nichtbelegung kommen generatorspezifische Standard-Namenskonventionen zur Anwendung.
  • Die Security-Regeln +eventTopicAccessRule, +methodTopicsAccessRule und +fieldTopicsAccessRule besitzen die Multiplizität 0..1; ohne Zuordnung greift das ungesicherte Standardverhalten der DDS-Domain.
• Field-Notifier-Bindung: Ein DdsFieldDeployment kann über die Komposition +notifier [0..1] exakt ein DdsEventDeployment einbinden, um Benachrichtigungen bei Wertänderungen zu übertragen.