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).
    • +capabilityRecord (0..* {ordered}, Komposition) → TagWithOptionalValue: Key-Value-Paare (key, sequenceOffset [0..1], value [0..1]) zur Attribut-Filterung bei der Service-Suche.
    • +sdClientConfig (0..1, Assoziation) → SomeipSdClientServiceInstanceConfig (Typ: ARElement).
    • +requiredEventGroup (0..*, Komposition) → SomeipRequiredEventGroup (Typ: Referrable).

Service Discovery & Timing-Konfigurationen

• SomeipSdClientServiceInstanceConfig (ARElement):
  • Attribut: priority: PositiveInteger [0..1] (Priorisierung von SD-Nachrichten).
  • Komposition: +initialFindBehavior (0..1) → InitialSdDelayConfig:
    • initialDelayMinValue: TimeValue, initialDelayMaxValue: TimeValue: 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):
    • subscribeEventgroupRetryDelay: TimeValue [0..1]: Intervall für erneute Subscriptions.
    • subscribeEventgroupRetryMax: PositiveInteger [0..1]: Maximale Retry-Anzahl bei ausbleibendem SubscribeEventgroupAck.
    • timeToLive: PositiveInteger: TTL-Feld im SOME/IP-SD-Header.
    • Komposition: +requestResponseDelay (0..1) → RequestResponseDelay: minValue, maxValue (Verzögerungsfenster für Antworten auf Unicast/Multicast-Trigger).

Aufzählungen

• «enumeration» ServiceVersionAcceptanceKindEnum:
  • minimumMinorVersion: Akzeptiert Service-Angebote mit ≥ requiredMinorVersion (Abwärtskompatibilität gemäß SemVer).
  • exactOrAnyMinorVersion: Erzwingt strikte Identität der Minor-Version oder akzeptiert Wildcards.

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

• Manifest-Generierung: Das Modell bildet die Schablone für ARXML-Generatoren. Fehlende optionale Attribute ([0..1]) fallen auf Default-Werte des SOME/IP-Stacks zurück (z. B. Wildcard 0xFFFF für requiredServiceInstanceId).
• Versions-Kompatibilität:
  • Steht versionDrivenFindBehavior auf minimumMinorVersion, muss der Stack sicherstellen, dass Erweiterungen in neueren Minor-Versionen (z. B. zusätzliche Events oder Datenfelder) die Deserialisierung des Clients nicht korrumpieren (Forward-Toleranz).
  • blocklistedVersion ermöglicht das gezielte Ausschließen fehlerhafter Server-Releases im Feld, ohne die Client-Software neu kompilieren zu müssen.
• Vermeidung von Busüberlastung (Ethernet Flooding):
  • Die Parameter in InitialSdDelayConfig und RequestResponseDelay sind zwingend so zu parametrieren, dass beim gleichzeitigen Hochfahren mehrerer ECUs Broadcast-/Multicast-Stürme (Synchronisations-Peaks) durch Randomisierung verhindert werden.
• E2E-Absicherung (PRS_E2E_00323):
  • Werden Events innerhalb der referenzierten SomeipEventGroup über E2E-Profile geschützt, muss die ara::com-Laufzeit anhand der SomeipRequiredEventGroup den korrekten E2E-Check-State aufsetzen, bevor deserialisierte Daten an die Applikationsschicht übergeben werden.