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: UploadablePackageElement):
  • Generisches Basiselement des Service-Deployments.
  • Hält Kompositionen zu generischen Event- und Field-Deployments.
• 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: UploadablePackageElement):
  • 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.
  • sign: Kryptografische Signatur / MAC (Integrität).
  • encryptAndSign: Signatur plus Verschlüsselung (Vertraulichkeit + Integrität).
  • signWithOriginAuthentication: Signatur mit Identitätsnachweis des Senders.
  • encryptAndSignWithOriginAuthentication: Vollschutz inklusive Quell-Authentifizierung.

Beziehungen & Kardinalitäten

• ServiceInterfaceDeployment ──◆ +eventDeployment [0..*] ──> ServiceEventDeployment
• ServiceInterfaceDeployment ──◆ +fieldDeployment [0..*] ──> ServiceFieldDeployment
• DdsServiceInterfaceDeployment ──> +methodTopicsAccessRule [0..1] ──> DdsTopicAccessRule
• DdsServiceInterfaceDeployment ──> +fieldTopicsAccessRule [0..1] ──> DdsTopicAccessRule
• DdsEventDeployment ──> +eventTopicAccessRule [0..1] ──> DdsTopicAccessRule
• DdsFieldDeployment ──◆ +notifier [0..1] ──> DdsEventDeployment

3. Dynamisches Verhalten & Sequenzablauf (Laufzeitabbildung)

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

• Generatoren & Manifest-Design (ARXML):
  • Die Modellierung in ARXML erfordert für jede ServiceInterface-Instanz mit DDS-Binding zwingend ein DdsServiceInterfaceDeployment.
  • Das Nicht-Konfigurieren von Topic-Namen ([0..1]) führt entweder zu Toolchain-Default-Regeln (z. B. Namensbildungsregeln aus Service-/Package-Pfaden) oder zu Validierungsfehlern im Adaptive Code-Generator.
• Stack- und Middleware-Konfiguration:
  • Das ara::com-DDS-Binding leitet aus diesen Klassen die QoS-Profile, DDS-Partitions und RTPS-Endpoints ab.
  • Wenn transportProtocol mehrfach belegt ist ([0..*]), muss der DDS-Stack Multihoming bzw. hybride Transports (z. B. Shared Memory für intra-Node und UDP für inter-Node) bereitstellen.
• DDS-Security Integration:
  • Die Zuweisung einer DdsTopicAccessRule bewirkt, dass der Generator Governance- und Permissions-Dateien (XML/PKCS#7/S/MIME) für das OMG DDS Security Subsystem erzeugt.
  • Entwickler müssen sicherstellen, dass bei aktivierten Schutzarten (encryptAndSign*, sign*) die entsprechenden Zertifikate und Crypto-Treiber (ara::crypto / HSM) auf der Zielplattform verfügbar und provisioniert sind.