Figure 9.13: Modeling of TimeSyncModuleInstantiation

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm (Ausschnitt aus dem AUTOSAR-M2-Metamodell).
• Architektur-Kontext: AUTOSAR Adaptive Platform (Manifest-Spezifikation, Release 18-03 / AP 1.4.0). Modelliert die allokierte Bereitstellung und Konfiguration des Functional Clusters Time Synchronization (ara::ts) auf einer konkreten Hardware-/Laufzeitumgebung (Machine) innerhalb des Machine Manifest.

2. Komponenten, Entitäten & Schnittstellen

• Machine («ARElement», «AtpStructureElement»):
  • Repräsentiert die physische oder virtualisierte Recheneinheit (ECU / Partition / OS-Instanz).
  • Besitzt das Attribut + trustedPlatformExecutableLaunchBehavior: TrustedPlatformExecutableLaunchBehaviorEnum.
  • Besitzt eine als «atpSplitable» gekennzeichnete Kompositionsbeziehung +moduleInstantiation mit Kardinalität 0..* zu Instanzen von AdaptiveModuleInstantiation.
• AdaptiveModuleInstantiation («Identifiable», abstrakt):
  • Basiselement für alle Instanziierungen von Adaptive-Plattform-Basisdiensten und Functional Clustern auf einer Maschine.
• NonOsModuleInstantiation (abstrakt):
  • Spezialisierung von AdaptiveModuleInstantiation. Kapselt alle Functional Cluster, die außerhalb des eigentlichen Betriebssystems (OS-Kernels) instanziiert werden.
• TimeSyncModuleInstantiation (konkret):
  • Spezialisierung von NonOsModuleInstantiation. Repräsentiert die konkrete Konfiguration des Time-Synchronization-Stacks auf der Maschine.
  • Hält per Komposition +timeBase mit Kardinalität 0..* logische Zeitbasen (TimeBaseResource).
• TimeBaseResource («Identifiable», abstrakt):
  • Abstrakte Basisklasse für alle vom TimeSync-Dienst verwalteten Zeitbasen.
  • Spezialisierungen (Generalisierungsbeziehungen):
    • PureLocalTimeBase: Ungesteuerte/rein lokale Zeitbasis (z. B. monotoner Hardware-Timer, CLOCK_MONOTONIC, ohne externe Netzwerksynchronisation).
    • SynchronizedMasterTimeBase: Zeitbasis, bei der die Maschine als Zeit-Master agiert (verteilt Zeitstempel aktiv über ein Netzwerk, z. B. gPTP / IEEE 802.1AS Grandmaster/Master).
    • SynchronizedSlaveTimeBase: Zeitbasis, bei der die Maschine als Zeit-Slave arbeitet (synchronisiert die lokale Uhr auf Basis extern empfangener Zeitsynchronisations-PDUs).

3. Dynamisches Verhalten & Sequenzablauf

• Klassifikation: Reines statisches Struktur- und Metamodell. Es sind keine Sequenzen, Zustandsübergänge oder Callbacks im Diagramm abgebildet.
• Laufzeitsemantik (abgeleitet):
  • Initialisierung (Startup): Der TimeSync-Daemon liest beim Hochfahren der Machine das kompilierte Machine Manifest aus.
  • Für jede TimeBaseResource werden hardwarenahe Taktgeber (z. B. PTP-Hardware-Clocks in Ethernet-PHY/MAC) initialisiert und initialen Drift-/Offset-Kompensationen unterzogen.
  • Master/Slave-Rolle: SynchronizedMasterTimeBase initiiert zyklische Sendeoperationen (Sync/Follow_Up/Announce); SynchronizedSlaveTimeBase aktiviert Empfangs- und Korrekturalgorithmen (PI-Regler für Frequenz-/Phasenanpassung).

4. Normative Relevanz & Entwickler-Hinweise

• Machine Manifest Definition:
  • Jede auf der Maschine genutzte Zeitbasis muss explizit unter TimeSyncModuleInstantiation.timeBase deklariert sein.
  • Ein Fehlen der Modellierung führt dazu, dass der TimeSync-Daemon keine Instanz instanziiert und ara::ts-Bindeglieder fehlschlagen.
• API- und Stack-Konfiguration (ara::ts):
  • Applikationen referenzieren über ihre Execution/Service Dependency die TimeBaseResource-Namen (Identifiable.shortName), um Zugriff auf ara::ts::TimeBase zu erhalten.
  • Für Entwickler von Netzwerk-Stacks und Treibern legt die Unterscheidung Master vs. Slave vs. PureLocal fest, ob Network Binding Module (z. B. IEEE 802.1AS über SOME/IP oder native Ethernet-Frames / CAN-TSyn) Treiber-Handles für TX-Timestamping (Master) oder RX-Timestamping (Slave) binden müssen.
• Generatoren-Einfluss:
  • Code-Generatoren leiten aus diesem Subbaum Konfigurationsstrukturen für den Time-Daemon, OS-Timer-Mappings, Socket-Bindings sowie maximal zulässige Jitter-/Sync-Schwellwerte ab.