Figure 6.6: SOME/IP Required Service Instance Deployment

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: AUTOSAR M2-Metamodell-Ausschnitt (UML-Klassendiagramm).
• Technischer Zweck: Modellierung des clientseitigen Service-Deployments (RequiredServiceInstance) für das SOME/IP-Transportprotokoll innerhalb der AUTOSAR Adaptive Platform (ara::com).
• Funktionale Einordnung: Definiert im Service-Instance-Manifest die Zuordnung einer logischen Service-Schnittstelle (RequiredApServiceInstance) zu netzwerkspezifischen SOME/IP-Parametern, SOME/IP-SD-Client-Timing-Verhalten, Filterkriterien für Instanz- und Versionsauflösung sowie Eventgruppen-Abonnement-Konfigurationen.

2. Komponenten, Entitäten & Schnittstellen

Zentrale Deployment-Entitäten

• RequiredApServiceInstance: Abstrakte Basisklasse für clientseitige Service-Instanzen im Adaptive-Manifest.
• RequiredSomeipServiceInstance:
  • Konkrete Spezialisierung (Generalisierung von RequiredApServiceInstance).
  • Attribute:
    • requiredMinorVersion: AnyVersionString [0..1]: Erwartete Minor-Version des Service-Interfaces.
    • requiredServiceInstanceId: AnyServiceInstanceId [0..1]: Explizite SOME/IP-Instanz-ID oder Wildcard (0xFFFF) für dynamisches Discovery.
    • versionDrivenFindBehavior: ServiceVersionAcceptanceKindEnum [0..1]: Bestimmt die Auswertung der Minor-Version.
  • Beziehungen & Aggregationen:
    • +blocklistedVersion (0..*, Komposition) → SomeipServiceVersion: Definiert explizit abgewiesene Versionen (majorVersion [0..1], minorVersion [0..1]).
    • +capabilityRecord (0..* {ordered}, Komposition) → TagWithOptionalValue: Key-Value-Paare (key [0..1], sequenceOffset [0..1], value [0..1]) zur Attribut-Filterung bei der Service-Suche.
    • +sdClientConfig (0..1, Assoziation) → SomeipSdClientServiceInstanceConfig (Typ: ARElement, UploadableDesignElement).
    • +requiredEventGroup (0..*, Komposition) → SomeipRequiredEventGroup (Typ: Referrable).

Service Discovery & Timing-Konfigurationen

• SomeipSdClientServiceInstanceConfig (ARElement, UploadableDesignElement):
  • Attribut: priority: PositiveInteger [0..1] (Priorisierung von SD-Nachrichten).
  • Komposition: +initialFindBehavior (0..1) → InitialSdDelayConfig:
    • initialDelayMinValue: TimeValue [0..1], initialDelayMaxValue: TimeValue [0..1]: Zufälliges Jitter-Intervall vor dem ersten FindService.
    • initialRepetitionsBaseDelay: TimeValue [0..1]: Basisintervall für Wiederholungen.
    • initialRepetitionsMax: PositiveInteger [0..1]: Maximale Anzahl der Wiederholungen in der Initialphase.
• SomeipRequiredEventGroup (Referrable):
  • Repräsentiert das clientseitige Interesse an einer Eventgruppe.
  • Assoziation: +eventGroup (0..1) → SomeipEventGroup (Identifiable / ARElement): Referenziert die Ziel-Eventgruppe (eventGroupId: PositiveInteger [0..1]).
  • Assoziation: +sdClientEventGroupTimingConfig (0..1) → SomeipSdClientEventGroupTimingConfig (ARElement, UploadableDesignElement):
    • subscribeEventgroupRetryDelay: TimeValue [0..1]: Intervall für erneute Subscriptions.
    • subscribeEventgroupRetryMax: PositiveInteger [0..1]: Maximale Retry-Anzahl bei ausbleibendem SubscribeEventgroupAck.
    • timeToLive: PositiveInteger [0..1]: TTL-Feld im SOME/IP-SD-Header.
    • Komposition: +requestResponseDelay (0..1) → RequestResponseDelay: minValue: TimeValue [0..1], maxValue: TimeValue [0..1] (Verzögerungsfenster für Antworten auf Unicast-Requests).

Hilfstypen & Enumerationen

• ServiceVersionAcceptanceKindEnum («enumeration»):
  • minimumMinorVersion: Akzeptiert Service-Angebote mit Minor-Version ≥ requiredMinorVersion.
  • exactOrAnyMinorVersion: Akzeptiert nur exakte Übereinstimmung mit requiredMinorVersion oder beliebige Versionen.
• SomeipServiceVersion: Definiert Versionen mit optionalen Attributen (majorVersion: PositiveInteger [0..1], minorVersion: PositiveInteger [0..1]).
• TagWithOptionalValue: Generisches Schlüssel-Wert-Paar (key: String [0..1], sequenceOffset: Integer [0..1], value: String [0..1]).

3. Dynamisches Verhalten & Sequenzablauf

Das Metamodell steuert die Zustandsmaschine des SOME/IP-Service-Discovery-Clients:

[Init / Startup]
       │
       ▼
[Initial Delay: Jitter (minValue..maxValue)]
       │
       ├─► Sende SOME/IP-SD FindService (Multicast/Unicast)
       │     └─► Exponentielles Backoff via initialRepetitionsBaseDelay (bis initialRepetitionsMax)
       │
       ▼
[Empfang SOME/IP-SD OfferService]
       │
       ├─► 1. Match Instance ID (requiredServiceInstanceId vs. Offer)
       ├─► 2. Versions-Validierung:
       │      ├─ Abgleich versionDrivenFindBehavior (exact vs. minimum)
       │      └─ Prüfung gegen blocklistedVersion (Drop bei Match)
       │
       ▼
[Service gematcht & ara::com Proxy erzeugt]
       │
       ▼
[Event-Subscription (SomeipRequiredEventGroup)]
       │
       ├─► Jitter / Verzögerung via RequestResponseDelay (minValue..maxValue)
       ├─► Sende SubscribeEventgroup (TTL = timeToLive)
       │
       ▼
[Warte auf SubscribeEventgroupAck]
       │
       ├─► Timeout / NACK ──► Retry via subscribeEventgroupRetryDelay (bis subscribeEventgroupRetryMax)
       └─► ACK empfangen ───► Event-Empfang aktiv (E2E/SOME/IP PDU Deserialisierung)

4. Normative Relevanz & Entwickler-Hinweise

• Normative Verbindlichkeit: Die Metaklassen bilden das Schema für SOME/IP-Client-Deployments im AUTOSAR Adaptive Platform Service-Instance-Manifest (ara::com).
• Klassifikations-Erweiterung: Durch die Einstufung von SomeipSdClientServiceInstanceConfig und SomeipSdClientEventGroupTimingConfig als UploadableDesignElement können diese Timing-Konfigurationen in modularen Design-Workflows separat verwaltet und hochgeladen werden.
• Lockerung von Multiplizitäten: Mehrere zuvor obligatorische Parameter (minorVersion in SomeipServiceVersion, key in TagWithOptionalValue, Delays in InitialSdDelayConfig und RequestResponseDelay sowie timeToLive in SomeipSdClientEventGroupTimingConfig) sind nun optional ([0..1]). Bei Nichtangabe greifen standardisierte Stack-Defaults.