Figure 7.3: Service contract versioning over time

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Evolutions- und Kompatibilitätsmodell (Lebenszyklus-/Versionsdiagramm über eine Zeitachse t).
• Technischer Zweck: Spezifikation der Versionierungsregeln für Service-Schnittstellen (ServiceInterface) innerhalb des AUTOSAR Adaptive Platform Communication Management (ara::com).
• Funktionale Einordnung: Definiert die Semantik von Major- und Minor-Versionierung für serviceorientierte Architekturen (SOA). Es regelt die Kriterien für Abwärtskompatibilität (Syntaktik vs. Semantik) zur Entkopplung unabhängiger Release-Zyklen von Service-Providern und Service-Consumern (Clients) über IPC oder Netzwerk-Bindings (z. B. SOME/IP).

2. Komponenten, Entitäten & Schnittstellen

• Entitäten (Metamodell / ARXML):
  • ServiceInterface: Formales ARXML-Servicedeskriptor-Artefakt (Service X), das Methoden, Events und Fields deklariert.
  • Service Catalog: Repositorium/Registry zur Erfassung und Bereitstellung aller historisch und aktuell verfügbaren Schnittstellenversionen eines Services (version 1.0 bis 3.0).
• Schnittstellenelemente von Service X:
  • Events: Asynchrone Push-Kommunikation (event a, event b, event d).
  • Methoden: Synchrone bzw. asynchrone RPCs (method k(...), method n()).
• Strukturelle Evolution im Diagramm:
  • v1.0 (Baseline): Events a, b; Methoden k(x,y), n().
  • v1.1 (Minor Increment): Ergänzung von event d; bestehende Events und Signaturen bleiben identisch.
  • v2.0 (Major Increment – Syntaktisch): Entfernung von event b; Signaturerweiterung von method k um Parameter u (k(x,y,u)).
  • v3.0 (Major Increment – Semantisch): Identisches Interface zu v2.0 (Events a, d; Methoden k(x,y,u), n()), jedoch mit verändertem Laufzeitverhalten.

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm modelliert keinen Laufzeit-Nachrichtenaustausch, sondern die zeitliche Übergangssemantik zwischen Interface-Revisionen:

1. Übergang v1.0 → v1.1 (backwards-compatible):
   • Klassifikation: Minor-Versionssprung.
   • Regel: Rein additive Änderung (Hinzufügen von event d). Bestehende Methodenverträge (k(x,y), n()) und Events (a, b) bleiben unberührt.
   • Kompatibilität: Ein auf v1.0 kompilierter Client kann ohne Re-Kompilierung/Anpassung mit einem v1.1-Provider interoperieren.
2. Übergang v1.1 → v2.0 (incompatible):
   • Klassifikation: Major-Versionssprung (syntaktischer Bruch).
   • Regel: Destruktive/mutierende Änderung durch Löschen eines Elements (event b) und Modifikation einer RPC-Signatur (k(x,y) → k(x,y,u) Serialisierungs- und Call-Layout ändern sich).
   • Kompatibilität: Vollständiger Schnittstellenbruch. Ein v1.x-Client kann v2.0 nicht konsumieren.
3. Übergang v2.0 → v3.0 (incompatible (behavior)):
   • Klassifikation: Major-Versionssprung (semantischer/funktionaler Bruch).
   • Regel: Trotz 100 % identischer ARXML-Schnittstellensignatur erzwingen veränderte funktionale Vor-/Nachbedingungen, Algorithmen oder Zustandsübergänge einen Major-Versionswechsel.
   • Kompatibilität: Verhindert Fehlverhalten von Bestands-Clients, die sich auf das bisherige funktionale Verhalten stützen.

4. Normative Relevanz & Entwickler-Hinweise

• Generierte C++-Artefakte (ara::com):
  • Versionssprünge schlagen sich direkt in generierten Skeleton- und Proxy-Klassen sowie Namensräumen nieder (z. B. Namensraum-Prefixing oder Typedefs basierend auf der Major-Version).
• Service Discovery & Binding (z. B. SOME/IP-SD):
  • Major Version: Wird im SOME/IP Service-Header und in SD-Nachrichten explizit abgeglichen. Service-Matching erfolgt strikt: Client-Major-Version muss exakt mit Provider-Major-Version übereinstimmen (Client.Major == Provider.Major).
  • Minor Version: Erlaubt asymmetrische Versionierung: Ein Provider mit Minor-Version Y_Prov bedient Clients mit Minor-Version Y_Cli, sofern Y_Prov ≥ Y_Cli.
• Entwickler-Richtlinien:
  • Reine Erweiterungen (Additive Minor Changes): Müssen so ausgelegt werden, dass ältere Bindings/Serialisierer unbekannte Payload-Anhänge sicher ignorieren oder optionale TLV-Felder nutzen.
  • Signatur-/Typänderungen: Jede Modifikation von Datentypen, Parametern oder Elementlöschungen erzwingt zwingend das Hochzählen der Major-Version in der ARXML-Modelldefinition (serviceInterface.majorVersion).
  • Semantische Verhaltensänderungen: Entwickler dürfen semantische Brüche niemals unter einer Minor-Version verstecken, da das Middleware-Routing und SOME/IP-SD rein typbasiert arbeiten und Verhaltensänderungen auf Netzwerkebene nicht erkennen können.