Figure 6.1: SOME/IP Service Insterface Deployment

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Ausschnitt des AUTOSAR Adaptive Platform Manifests (AUTOSAR_EXP_ARAComAPI, R22-11).
• Technischer Zweck: Spezifikation des Deployment-Metamodells für das SOME/IP-Binding. Es bildet die abstrakte, protokollunabhängige Servicedefinition (ServiceInterface) auf die konkreten On-Wire-Artefakte des SOME/IP-Netzwerkprotokolls ab.
• Architektonische Einordnung: Definiert die Datenstrukturen in den Execution-/Service-Instance-Manifesten (ARXML), die der Codegenerator für die Kommunikations-Middleware (ara::com) benötigt, um Serialisierung, Dispatching, Protokoll-Header (Service-ID, Method-ID, Event-ID) sowie Socket-Eigenschaften (TCP/UDP) bindungsspezifisch zu instanziieren.

2. Komponenten, Entitäten & Schnittstellen

Abstrakte Basisklassen (Metamodell-Ebene)

• ServiceInterfaceDeployment («UploadableDesignElement»): Abstrakter Wurzelcontainer für das Protokolldeployment eines Service Interfaces.
  • Aggregiert per Komposition (jeweils mit «atpVariation,atpSplitable»):
    • +methodDeployment [0..*]: ServiceMethodDeployment
    • +fieldDeployment [0..*]: ServiceFieldDeployment
    • +eventDeployment [0..*]: ServiceEventDeployment
• ServiceMethodDeployment («Identifiable»): Abstrakte Basis für methodenbezogene Deployment-Eigenschaften.
• ServiceEventDeployment («Identifiable»): Abstrakte Basis für eventbezogene Deployment-Eigenschaften.
• ServiceFieldDeployment («Identifiable»): Abstrakte Basis für feldspezifische Deployment-Eigenschaften.

Konkrete SOME/IP-Klassen

• SomeipServiceInterfaceDeployment (Spezialisierung von ServiceInterfaceDeployment):
  • serviceInterfaceId: PositiveInteger [0..1]: 16-Bit SOME/IP Service-Identifier.
  • Komposition +serviceInterfaceVersion [0..1] → SomeipServiceVersion:
    • majorVersion: PositiveInteger [0..1]
    • minorVersion: PositiveInteger [0..1]
  • Komposition +eventGroup [0..*] → SomeipEventGroup («Identifiable»):
    • eventGroupId: PositiveInteger [0..1]: Identifier für SOME/IP-SD (Service Discovery) Eventgruppen.
    • Assoziation +event [0..*] → SomeipEventDeployment (Zuordnung von Events zu einer Multicast-/Abonnement-Gruppe).
• SomeipEventDeployment (Spezialisierung von ServiceEventDeployment):
  • eventId: PositiveInteger [0..1]: 16-Bit SOME/IP Event-ID.
  • transportProtocol: TransportLayerProtocolEnum [0..1]: Protokollzuweisung (udp / tcp).
  • serializer: SerializationTechnologyEnum [0..1]: Serialisierungsmechanismus (someip / signalBased).
  • maximumSegmentLength: PositiveInteger [0..1]: Maximale SOME/IP-TP-Payload-Länge für Segmentierung.
  • segmentReceptionTimeoutTime: TimeValue [0..1]: Timeout für die Reassemblierung von SOME/IP-TP-Segmenten.
  • separationTime: TimeValue [0..1]: Mindestabstand zwischen Segmenten (Traffic Shaping).
  • burstSize: PositiveInteger [0..1]: Maximale Anzahl unmittelbar aufeinanderfolgender TP-Segmente.
  • Komposition +eventReceptionDefaultValue [0..1] → ValueSpecification: Initialer Standardwert bei Event-Empfang.
• ValueSpecification (abstrakt):
  • shortLabel: Identifier [0..1]: Optionaler Bezeichner der Wertspezifikation.
• SomeipMethodDeployment (Spezialisierung von ServiceMethodDeployment):
  • methodId: PositiveInteger [0..1]: 16-Bit SOME/IP Method-ID.
  • transportProtocol: TransportLayerProtocolEnum [0..1]: Protokollzuweisung (udp / tcp).
  • Getrennte SOME/IP-TP- und Flow-Control-Parameter für Request und Response:
    • maximumSegmentLengthRequest / maximumSegmentLengthResponse: PositiveInteger [0..1]
    • segmentReceptionTimeoutTimeRequest / segmentReceptionTimeoutTimeResponse: TimeValue [0..1]
    • separationTimeRequest / separationTimeResponse: TimeValue [0..1]
    • burstSizeRequest / burstSizeResponse: PositiveInteger [0..1]
• SomeipFieldDeployment (Spezialisierung von ServiceFieldDeployment):
  • Dekomponiert das abstrakte Field in bis zu drei konkrete SOME/IP-Primitive:
    • +get [0..1] → SomeipMethodDeployment (Getter als Request/Response-Call)
    • +set [0..1] → SomeipMethodDeployment (Setter als Request/Response-Call)
    • +notifier [0..1] → SomeipEventDeployment (Wertänderungs-Notification als Event)

Enumerationen

• TransportLayerProtocolEnum: literals {udp, tcp}
• SerializationTechnologyEnum: literals {someip, signalBased} (Unterscheidung zwischen Standard-SOME/IP-Serialisierung und signalbasiertem PDU-Mapping).

3. Dynamisches Verhalten & Sequenzablauf

Als statisches Metamodell zeigt das Diagramm keine Laufzeitsequenzen; es determiniert jedoch das Laufzeitverhalten des ara::com-Stacks:

• Subscription & Event-Routing: Die Relation SomeipEventGroup → +event definiert, welche Events über dieselbe eventGroupId per SOME/IP-SD (Subscribe Eventgroup) abonniert werden. Clients empfangen Benachrichtigungen erst nach erfolgreichem Subscription-ACK auf Gruppenebene.
• Field-Operationen: Ein Zugriff auf ein Field resultiert abhängig von der Operation im Aufruf der verlinkten Entitäten:
  • Get() triggert einen RPC an die methodId der +get-Assoziation.
  • Set() triggert einen RPC an die methodId der +set-Assoziation.
  • Wertänderungen werden über die eventId der +notifier-Assoziation gepublisht.
• Transport-Protokoll-Segmentierung (SOME/IP-TP): Überschreitet die serialisierte Payload maximumSegmentLength(Request/Response), aktiviert der Stack zwingend das SOME/IP-TP. Die Parameter burstSize und separationTime erzwingen asynchrone Drosselung/Pacing auf Socket-Ebene, um Pufferüberläufe am Empfänger zu verhindern.

4. Normative Relevanz & Entwickler-Hinweise

• Konfiguration (ARXML):
  • Entwickler müssen sicherstellen, dass serviceInterfaceId, methodId und eventId im On-Wire-Format eindeutig sind. Die 32-Bit SOME/IP Message ID setzt sich normativ zusammen aus: $$\text{Message ID} = (\text{serviceInterfaceId} \ll 16) \mid (\text{methodId} \text{ bzw. } \text{eventId})$$
  • Bit 15 des Sub-Identifiers unterscheidet normativ zwischen Methoden (0) und Events/Notifiern (1).
• Stack- und Codegenerator-Auswirkung:
  • Der Codegenerator erzeugt aus SomeipServiceInterfaceDeployment die skeletons- und proxyseitigen Dispatch-Tabellen.
  • Die Wahl von transportProtocol bestimmt, ob der Stack POSIX-Sockets für TCP (SOCK_STREAM) oder UDP (SOCK_DGRAM) bindet bzw. verbindet.
• Signal-based Gatewaying:
  • Ist serializer = signalBased gesetzt, deserialisiert der Stack die Payload nicht nach SOME/IP-Transformationsregeln, sondern mappt Felder direkt auf PDU-Signale (wesentlich für Übergänge zur Classic Platform / CAN/LIN-Bussystemen).
• Entwickler-Falle (Field-Deployment):
  • Ein SomeipFieldDeployment besitzt keine eigene ID auf dem Bus; es existiert zur Laufzeit ausschließlich über seine aggregierten Komponenten (+get, +set, +notifier). Fehlt z. B. die +notifier-Referenz, unterstützt das Field im Deployment kein Subscribe/Notify, selbst wenn das Interface dies vorsieht.