Figure 15.5: Modeling of TimeSyncPortPrototypeToTimeBaseMapping

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (Ausschnitt aus dem AUTOSAR-Metamodell der Adaptive Platform, M2-Ebene).
• Technischer Zweck: Spezifikation der Zuordnung (TimeSyncPortPrototypeToTimeBaseMapping) zwischen einem softwareseitigen Anforderungs-Port (RPortPrototype) eines Prozesses und der maschinenseitig bereitgestellten physischen bzw. logischen Zeitbasis (TimeBaseResource).
• Funktionale Einordnung: Verortet im Manifest-Modell (Execution-/Machine-Manifest). Es schlägt die Brücke zwischen dem applikationsseitigen Schnittstellendesign (TimeSynchronizationInterface zur Nutzung von ara::tsync) und der plattformspezifischen Zeitressource der Maschine (z. B. IEEE 802.1AS / PTP, CAN-TS oder lokale Oszillatoren).

2. Komponenten, Entitäten & Schnittstellen

Metamodell-Klassen & Hierarchien

1. Mapping-Element:
   • TimeSyncPortPrototypeToTimeBaseMapping: Spezialisiert UploadablePackageElement. Fungiert als zentraler Binder im Manifest.
2. Applikations- & Port-Ebene (Links im Diagramm):
   • RPortPrototype (Spezialisierung von AbstractRequiredPortPrototype): Repräsentiert den Client-Port der Adaptive Application, über den die Zeitsynchronisation angefordert wird.
   • PortInterface (Spezialisierung von ARElement, AtpBlueprint, AtpBlueprintable, AtpType): Typisiert den Port.
   • TimeSynchronizationInterface: Abstraktes Basis-Interface für Zeitsynchronisation, erbt von PortInterface.
     • TimeSynchronizationMasterInterface: Stellt Zeitinformationen für das Gesamtsystem bereit; besitzt das Attribut +timeBaseKind : TimeSynchronizationKindEnum.
     • TimeSynchronizationSlaveInterface: Synchronisiert die lokale Zeit gegen eine externe Master-Quelle; besitzt das Attribut +timeBaseKind : TimeSynchronizationKindEnum.
     • TimeSynchronizationPureLocalInterface: Bietet Zugriff auf eine rein lokale, monotonic/nicht netzwerk-synchronisierte Zeitbasis.
3. Plattform- & Ressourcen-Ebene (Rechts im Diagramm):
   • Process (Spezialisierung von ARElement, AtpClassifier): Laufzeitinstanz einer auszuführenden Applikation auf der Adaptive-Maschine.
   • TimeBaseResource (Spezialisierung von Identifiable): Abstrakte Repräsentation einer konkreten Hardware-/OS-Zeitbasis der Maschine.
     • SynchronizedMasterTimeBase: Plattform-Zeitbasis im Master-Betrieb.
     • SynchronizedSlaveTimeBase: Plattform-Zeitbasis im Slave-Betrieb (extern synchronisiert).
     • PureLocalTimeBase: Lokale Zeitbasis ohne externe Kopplung.

Beziehungen & Kardinalitäten

• TimeSyncPortPrototypeToTimeBaseMapping → RPortPrototype:
  • Assoziationsende: +timeSyncPortPrototype (Kardinalität 0..1).
  • Stereotyp: «instanceRef» (Kontextsensitive Instanzreferenz auf den Port im Kontext der Prozess-/Software-Komponenten-Hierarchie).
• TimeSyncPortPrototypeToTimeBaseMapping → Process:
  • Assoziationsende: +process (Kardinalität 0..1). Identifiziert den Prozess-Kontext, zu dem der Port gehört.
• TimeSyncPortPrototypeToTimeBaseMapping → TimeBaseResource:
  • Assoziationsende: +timeBaseResource (Kardinalität 0..1). Referenziert die zugeordnete Plattform-Zeitbasis.
• RPortPrototype → PortInterface:
  • Assoziationsende: +requiredInterface (Kardinalität 1, redefiniert atpType).
  • Stereotyp: «isOfType». Typisiert den Port spezifisch mit einer TimeSynchronizationInterface-Ausprägung.

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches Metamodell für Bereitstellungsdaten (Manifest) handelt, erfolgt der Ablauf phasenbasiert über Build- und Startzeit:

1. Konfigurations- & Modellierungszeit:
   • Der Systemdesigner modelliert einen RPortPrototype an einer Software-Komponente und typisiert ihn z. B. als TimeSynchronizationSlaveInterface.
   • Im Manifest wird ein TimeSyncPortPrototypeToTimeBaseMapping instanziiert, das genau diesen Port (über «instanceRef») innerhalb des Ziel-Process mit der definierten SynchronizedSlaveTimeBase der Maschine verknüpft.
2. Generierungs- & Deployment-Phase:
   • Der Manifest-Compiler validiert die Typverträglichkeit (z. B. Slave-Port auf Slave-Ressource) und generiert die Laufzeit-Deskriptoren für die Adaptive Plattform.
3. Laufzeit-Initialisierung (Startup-Phase):
   • Execution Management (EM) instanziiert und startet den Process.
   • Der Functional Cluster Time Synchronization (ara::tsync) liest das Manifest aus, instanziiert die Middleware-Endpunkte und bindet den Port an die Hardware-Clock bzw. den PTP-Treiberstack (Ethernet IEEE 802.1AS / CAN-TS).
   • Die Applikation öffnet den Port via C++ API (ara::tsync) und erhält direkten, typsicheren Zugriff auf die zugeordnete Zeitbasis.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur-Symmetrie (TPS_MANI_03548):
  • Es gilt eine strikte semantische 1:1-Entsprechung zwischen Interface-Klasse und TimeBase-Klasse:
    • TimeSynchronizationMasterInterface $\longleftrightarrow$ SynchronizedMasterTimeBase
    • TimeSynchronizationSlaveInterface $\longleftrightarrow$ SynchronizedSlaveTimeBase
    • TimeSynchronizationPureLocalInterface $\longleftrightarrow$ PureLocalTimeBase
  • Modellierungsfehler (z. B. Mapping eines TimeSynchronizationMasterInterface auf eine PureLocalTimeBase) müssen von Validierungs-Tools zur Entwurfszeit als ungültig abgelehnt werden.
• Prozess-Isolation & Instanzauflösung (RS_MANI_00040):
  • Da Ports im Software-Design abstrakt definiert werden, stellt «instanceRef» über die Verknüpfung mit +process sicher, dass derselbe Port-Typ in unterschiedlichen Prozessen auf getrennte Zeitbasen oder Zeitdomänen der Maschine gemappt werden kann.
• Auswirkungen auf die Anwendungsentwicklung (ara::tsync):
  • Der Applikationscode bleibt vollständig entkoppelt von der Netzwerktopologie und Hardware-Uhr. Ob eine Slave-Zeitbasis über Ethernet (PTP/IEEE 1588) oder CAN synchronisiert wird, entscheidet allein die Konfiguration der TimeBaseResource im Manifest; die C++-Schnittstelle der Anwendung ändert sich nicht.