Figure 6.9: DDS Provided Service Instance Deployment

1. Diagrammtyp & Architektur-Kontext

• Typ: UML-Klassendiagramm (Ausschnitt des AUTOSAR Adaptive Platform Metamodells / Service Instance Manifest).
• Architektur-Kontext: Spezifikation des DDS-Netzwerk-Bindings innerhalb von ara::com (AUTOSAR Adaptive Platform, Release R22-11).
• Funktionaler Zweck: Modellierung des Deployments einer serverseitigen Service-Instanz (ProvidedApServiceInstance) auf die Data Distribution Service (DDS) Middleware. Das Metamodell definiert die Zuordnung von abstrakten Service-Interfaces, Events und Fields zu konkreten DDS-Instanzen, Discovery-Mechanismen, Identifikationsstrategien und DDS-spezifischen Quality-of-Service (QoS)-Parametern.

2. Komponenten, Entitäten & Schnittstellen

Metamodell-Klassen & Hierarchie

• AdaptivePlatformServiceInstance (abstrakt, Basis: UploadableDesignElement): Abstrakte Basisklasse aller Service-Instanzen im Adaptive System.
  • Assoziation +serviceInterfaceDeployment (Kardinalität 0..1): Referenziert das zugehörige ServiceInterfaceDeployment.
• ProvidedApServiceInstance (Basis: AdaptivePlatformServiceInstance): Repräsentiert die serverseitig angebotene (provided) Service-Instanz.
• DdsProvidedServiceInstance (Spezialisierung von ProvidedApServiceInstance, erweitert durch DdsServiceInstanceProps): Konkrete Ausprägung einer bereitgestellten Service-Instanz für den DDS-Kommunikationsstack.
  • Attribute:
    • +discoveryType: DdsServiceInstanceDiscoveryTypeEnum [0..1]: Bestimmt den Discovery-Pfad.
    • +resourceIdentifierType: DdsServiceInstanceResourceIdentifierTypeEnum [0..1]: Definiert die Adressierungs-/Kapselungsstrategie für DDS-Entities.
    • +serviceInstanceId: PositiveInteger [0..1]: Eindeutige numerische Instanz-ID des Services.
• ServiceInterfaceDeployment (Basis: UploadableDesignElement): Protokollspezifische Konfiguration des Service-Interfaces. Hält per Komposition (1 zu 0..*, annotiert mit «atpVariation,atpSplitable»):
  • +eventDeployment: Liste von ServiceEventDeployment.
  • +fieldDeployment: Liste von ServiceFieldDeployment.
• ServiceEventDeployment (Basis: ServiceInterfaceDeploymentElement): Deployment-Konfiguration eines konkreten Service-Events.
• ServiceFieldDeployment (Basis: ServiceInterfaceDeploymentElement): Deployment-Konfiguration eines Service-Fields (Getter/Setter/Notifier).
• DdsEventQosProps (Spezialisierung von DdsQosProps): DDS-spezifische QoS-Richtlinien für Events.
  • Komposition: DdsProvidedServiceInstance aggregiert +eventQosProps (0..*).
  • Assoziation: Referenziert +event (ServiceEventDeployment, Kardinalität 0..1).
• DdsFieldQosProps (Spezialisierung von DdsQosProps): DDS-spezifische QoS-Richtlinien für Field-Notifier.
  • Komposition: DdsProvidedServiceInstance aggregiert +fieldNotifierQosProps (0..*).
  • Assoziation: Referenziert +field (ServiceFieldDeployment, Kardinalität 0..1).

Enumerationen

• DdsServiceInstanceDiscoveryTypeEnum:
  • domainParticipantUserDataQos: Discovery erfolgt über das standardisierte DDS-Built-in-Discovery-Protokoll (SPDP/SEDP) mittels Payload im UserDataQosPolicy des DomainParticipant.
  • topic: Service-Ankündigung erfolgt über dedizierte DDS-Discovery-Topics.
• DdsServiceInstanceResourceIdentifierTypeEnum:
  • partition: Trennung/Adressierung unterschiedlicher Service-Instanzen erfolgt über DDS-Partitions innerhalb derselben Topics.
  • topicPrefix: Instanztrennung erfolgt durch dynamischen Prefix im Topic-Namen.
  • instanceId: Unterscheidung einzelner Service-Instanzen über den DDS-Instanzschlüssel (Instance Handle).

3. Dynamisches Verhalten & Sequenzablauf

Das statische Metamodell steuert die Laufzeitphasen des ara::com-DDS-Bindings:

1. Service Offering (Skeleton::OfferService()):
   • Die Binding-Schicht liest DdsProvidedServiceInstance.
   • Discovery-Phase: Je nach discoveryType propagiert der Stack die serviceInstanceId via DDS DomainParticipantQos.user_data oder publiziert eine Ankündigung auf dem konfigurierten Announcement-Topic.
2. DDS-Entity-Initialisierung:
   • Anlegen der DataWriter für Events und Field-Notifier.
   • Namespace-Auflösung gemäß resourceIdentifierType:
     • Bei partition: Zuweisung der Publisher/DataWriter zu einer spezifischen DDS-Partition.
     • Bei topicPrefix: Generierung topikspezifischer Topic-Strings.
     • Bei instanceId: Zuweisung des Key-Werts in den serialisierten CDR-Samples.
3. QoS-Parametrisierung:
   • Die in DdsEventQosProps und DdsFieldQosProps hinterlegten Parameter (z. B. Reliability [Reliable vs. Best-Effort], Durability [Volatile vs. Transient-Local], History, Deadline) werden direkt in die DataWriterQos der jeweiligen Event-/Field-Topics injiziert.

4. Normative Relevanz & Entwickler-Hinweise

• ARXML-Generierung / Manifest-Konfiguration:
  • Jede DDS-basierte Server-Instanz erfordert ein valides DdsProvidedServiceInstance-Element im ServiceInstanceManifest.
  • serviceInstanceId muss innerhalb der DDS-Domain eindeutig sein, sofern resourceIdentifierType nicht auf partition oder topicPrefix isoliert ist.
• Stack-/Binding-Implementierung (ara::com DDS-Plugin):
  • Entwickler des Middleware-Stacks müssen sicherstellen, dass Inkompatibilitäten zwischen discoveryType und resourceIdentifierType zur Generierzeit validiert werden.
  • Late-Joiner-Semantik für Fields erfordert in DdsFieldQosProps zwingend DurabilityQosPolicyKind = TRANSIENT_LOCAL_DURABILITY_QOS in Kombination mit passendem HistoryQosPolicyKind.
• Applikations-Entwickler:
  • Vollständige Abstraktion auf C++-API-Ebene (ara::com::Skeleton). Das Mapping auf Topics, Partitions und DDS-QoS erfolgt deklarativ über das Manifest und beeinflusst Determinismus, Speicherallokation im DDS-Treiber und Echtzeitverhalten (z. B. blockierendes Senden bei vollen DataWriter-Queues unter RELIABLE).