Figure 7.4: Service contract versioning flow

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Metamodell-, Workflow- und Target-Deployment-Diagramm (Methodology & Lifecycle Flow) mit vertikaler Trennung von Offboard-Entwicklungsprozess und Onboard-Laufzeitumgebung.
• Funktionaler Kontext: Spezifikation des Service Contract Versioning innerhalb des Communication Managements der AUTOSAR Adaptive Platform (ara::com).
• Architektonischer Zweck: Veranschaulichung der strikten Entkopplung zwischen der Programmierschnittstellen-Ebene (Design-Phase, C++-Typsystem via Proxy/Skeleton, Version x.y) und der Netzwerk-/Übertragungs-Ebene (Deployment-Phase, Wire-Format/Protokoll-Binding via Manifeste, Version a.b) durch ein explizites Version Mapping.

2. Komponenten, Entitäten & Schnittstellen

Entwurfs- und Deployment-Ebene (Offboard)

• Design Phase (1):
  • Define Services: Aktivität zur Modellierung des abstrakten Service-Vertrags.
  • Service Interface Description: ARXML-Modellartefakt (ServiceInterface), annotiert mit der semantischen Service Contract Version (version x.y).
  • Skeleton & Proxy: Aus dem ServiceInterface generierte C++-Schnittstellenklassen (ara::com-Bindeglied zur Applikation).
  • Develop Software / Adaptive Application: Applikations-Quellcode, der gegen die generierten C++-Signaturen der Version x.y implementiert ist.
  • Develop Platform and Configure Machine / Machine Manifest: Plattform-/Hardware-Topologie, Netzwerkendpunkte und OS-Konfiguration.
  • Integrate Software: Erzeugt das kompilierte Executable sowie das zugehörige Application Manifest.
  • Define and Configure Service Instances: Zuordnung abstrakter Service-Interfaces zu konkreten Instanzen und Kommunikationsendpunkten unter Hinzuziehung des Machine Manifest.
• Deployment Phase (2):
  • Version Mapping: Relation zwischen abstrakter Design-Version (x.y) und deploymentspezifischer Protokoll-Version (a.b).
  • Service Interface SID: Eindeutige Service-ID auf Protokollebene (z. B. SOME/IP Service ID 99), differenziert in Provided Service (Server/Skeleton) und Required Service (Client/Proxy).
  • Deployment-Versionierung (version a.b): Wire-Format-Attribute im ServiceInstanceToMachineMapping bzw. Service-Deployment-Manifest:
    • <SERVICE-INTERFACE-ID> (z. B. 99)
    • <SERVICE-INTERFACE-VERSION> mit <MAJOR-VERSION> (z. B. 1) und <MINOR-VERSION> (z. B. 0).
  • SW Package: Bereitstellungsartefakt für das Update and Configuration Management (UCM), bestehend aus:
    • executable (Binärdatei),
    • Application Manifest (Startkonfiguration, Ressourcenlimits, OS-Scheduling),
    • Service Instance Manifest (Bindings, Port-Konfiguration, SOME/IP-/IPC-Deployment, Version a.b).

Zielsystem-Ebene (Onboard / Machine A)

• SW Configuration Management (UCM): Empfängt das SW-Paket offboard, übernimmt Verifikation, Authentifizierung, Entpacken und Installation.
• installed executable 1: Installiertes Binary auf dem persistenten Speicher.
• processed manifests / data base: Verarbeitete Konfigurationsmetadaten zur schnellen Abfrage durch Plattform-Dienste.
• Execution Management (EM): Liest die Manifest-Datenbank, konfiguriert Prozessparameter, steuert Start-, Laufzeit- und Shutdown-Zustände.
• process 1-1 (loaded executable instance): Aktive Laufzeitinstanz der Adaptive Application, kommuniziert über standardisierte Schnittstellen mit:
  • OS: POSIX PSE51-Schnittstellen (Scheduling, IPC, Memory Management),
  • Execution Management API: Zustandsrückmeldungen (ReportExecutionState),
  • other functional clusters: Insbesondere ara::com (Kommunikationsstack), ara::diag, ara::per.

3. Dynamisches Verhalten & Sequenzablauf

I. Modellierungs- und Generierungsphase (Design-Time)

1. Definition des abstrakten Service-Interfaces mit Methoden, Events und Fields inklusive Vergabe der Service Contract Version x.y.
2. Toolgestützte Codegenerierung der typisierten C++-Proxy- und Skeleton-Klassen basierend auf x.y.
3. Kompilierung der Adaptive Application gegen diese Header-Dateien (strenge Bindung des Binaries an C++-Signaturen und Typdefinitionen).

II. Konfigurations- und Paketierungsphase (Deployment-Time)

1. Instanziierung des Services für die Zielmaschine (Service Instance Manifest).
2. Konfiguration des Protokoll-Deployments (z. B. SOME/IP, IPC) mit Vergabe der Wire-Version a.b (MAJOR-VERSION, MINOR-VERSION).
3. Festlegung des Version Mapping zwischen x.y und a.b im Manifest.
4. Bündelung von Executable, Application Manifest und Service Instance Manifest in ein standardisiertes SW Package.

III. Installations- und Laufzeitphase (Target Execution)

1. Transfer des SW Package auf Machine A.
2. SW Configuration Management authentifiziert das Paket, platziert das Binary (installed executable 1) und aktualisiert die Manifest-Datenbank.
3. Execution Management startet process 1-1 gemäß den Vorgaben des Application Manifests.
4. Zur Laufzeit initiiert process 1-1 Service-Discovery-Aufrufe (OfferService oder FindService) über ara::com:
   • Die Applikationsschicht arbeitet ausschließlich mit C++-Objekten der Schnittstelle x.y.
   • Der Communication-Management-Stack serialisiert/deserialisiert Payloads und initialisiert SOME/IP-SD-Nachrichten unter Verwendung der im Service Instance Manifest hinterlegten Protokoll-Version a.b.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung von Quellcode- und Netzwerkkompatibilität:
  • Eine Änderung der Design-Version x.y (C++ Interface) erzwingt ein Re-Compiling der Applikation, muss aber nicht zwingend die Wire-Version a.b brechen, sofern das Serialisierungsformat kompatibel bleibt.
  • Umgekehrt erlaubt das Mapping, die Deployment-Version a.b (z. B. Protokolloptimierungen, SOME/IP-Header-Anpassungen) zu ändern, ohne den Sourcecode der Adaptive Application modifizieren zu müssen.
• SOME/IP Versioning Semantik:
  • MAJOR-VERSION (a): Definiert inkompatible Änderungen auf Feldbusebene. Service Discovery matcht Clients und Server nur bei exakter Übereinstimmung der Major-Version. Ein Mismatch führt zum Scheitern von FindService/OfferService.
  • MINOR-VERSION (b): Rückwärtskompatible Erweiterungen (z. B. Hinzufügen optionaler TLV-Parameter oder neuer Methoden). Server mit höherer Minor-Version können Anfragen von Clients mit niedrigerer Minor-Version bedienen.
• Konfigurations-Integrität:
  • Entwickler und Integratoren müssen sicherstellen, dass die im Manifest deklarierte Mapping-Beziehung zwischen x.y und a.b exakt den Annahmen des Codegenerators für Serialisierer und Deserialisierer entspricht.
  • Diskrepanzen zwischen dem zur Compile-Zeit verwendeten Header-Stand (x.y) und dem im Service Instance Manifest hinterlegten Deployment (a.b) führen zu unbemerkten Deserialisierungsfehlern, Frame-Drops im Stack oder Laufzeitabbrüchen beim Service-Binding.