Figure 7.2: ara::log Modeled Message Generator

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Generatormodell / Werkzeugfluss-Diagramm (Build-time Artifact Transformation Pipeline).
• Technischer Zweck & funktionale Einordnung: Veranschaulicht den Codegenerierungsprozess für typisierte, modellierte DLT-Nachrichten (Modeled Messages) innerhalb von AUTOSAR Adaptive Platform (ara::log). Es bildet ARXML-Modellbeschreibungen (LogAndTraceMessageCollectionSet, LogAndTraceInterface) deterministisch auf C++-Headerdateien (messages.h), Namensräume und Message-Instanzen ab, um standardisiertes, nicht-verboses DLT-Logging zur Compile-Zeit typsicher bereitzustellen.

2. Komponenten, Entitäten & Schnittstellen

• Eingangsartefakt (x_messages.arxml):
  • LogAndTraceInterface: Definiert den Basis-Namespace der Applikation über eine geordnete Sequenz von Symbol-Attributen (.symbol[1] = Apd, .symbol[2] = MyApp → apd::myapp).
  • LogAndTraceMessageCollectionSet: Gruppierungscontainer für logisch zusammengehörige Log-Nachrichten (hier Instanzen DltMsgs1 und DltMsgs2).
  • DltMessage: Repräsentiert die einzelne modellierte Log-PDU bzw. DLT-Nachricht mit spezifischen Parametern, Payload-Definitionen und 32-Bit Message-ID (.shortName = SpeedMsg1, SpeedMsg2).
• Generator-Komponente:
  • ARA Log Modeled Message Generator: Transformator, der die ARXML-Metadaten verarbeitet und die plattformspezifischen C++14/C++17-Header erzeugt.
• Ausgangsartefakte & Dateisystem-Struktur:
  • Getrennte Verzeichnispfade basierend auf Modell-Hierarchie: apd/myapp/.../dltmsgs1/ und apd/myapp/.../dltmsgs2/.
  • Generierte Header messages.h mit vollqualifizierten Include-Guards (APD_MYAPP_DLTMSGS1_H_, APD_MYAPP_DLTMSGS2_H_).
  • Typisierte Symbole im Ziel-Namespace:
    • Typdefinitionen: <Namespace>::<CollectionName>::<MessageName>Type (z. B. apd::myapp::dltmsgs1::SpeedMsg1Type).
    • Vorinstanziierte Nachrichtenobjekte: <MessageName> (z. B. SpeedMsg1, SpeedMsg2).

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um einen statischen Codegenerierungsschritt zur Entwurfs-/Build-Zeit handelt, existiert kein dynamischer Laufzeit-Kontrollfluss. Der Generierungsablauf erfolgt linear:

1. Parsing: Einlesen der LogAndTraceInterface- und LogAndTraceMessageCollectionSet-Pakete aus der Manifest-Konfiguration (*.arxml).
2. Namensraum-Auflösung: Verkettung von LogAndTraceInterface.symbol[] mit dem shortName des jeweiligen LogAndTraceMessageCollectionSet zu eindeutigen C++-Namespaces (apd::myapp::dltmsgs1).
3. Kollisionsvermeidung: Identische DltMessage.shortName-Bezeichner (SpeedMsg1, SpeedMsg2) in unterschiedlichen CollectionSets werden durch isolierte Sub-Namespaces und separate Verzeichnispfade konfliktfrei gekapselt.
4. Code-Emittierung: Erzeugen der Header messages.h inklusive typsicherer Structs/Klassen für die serialisierbaren DLT-Payloads sowie statischer Instanzen.

4. Normative Relevanz & Entwickler-Hinweise

• SWS-Konformität (SWS_LOG_00244, SWS_LOG_00245): Der Generator setzt die vertraglichen Namensraum- und Header-Generierungsregeln für modelliertes Logging um. Entwickler binden die generierten Header dateipfadgenau ein (#include "apd/myapp/.../dltmsgs1/messages.h").
• Non-Verbose Mode Logging (RS_LT_00003, RS_LT_00049): Durch modellierte Nachrichten entfällt das Parsen von ASCII-Strings zur Laufzeit. Die Payload-Serialisierung erfolgt direkt über die generierten Datentypen; auf dem Bus (DLT-Daemon/Logging-Socket) werden kompakte Message-IDs anstelle von Textstrings übertragen. Dies minimiert Buslast und CPU-Overhead auf dem Zielsystem.
• Applikations-API: Entwickler übergeben die generierten Instanzen (SpeedMsg1) typisiert an den Stream-Operator von ara::log::Logger::LogVerbose() bzw. die dedizierten Modeled-Message-Log-Methoden (logger.Log(SpeedMsg1, ...)); Typüberprüfungen für Argumente erfolgen vollständig zur Compile-Zeit.