module ara::log — Log and Trace

Le cluster fonctionnel Log and Trace fournit l'infrastructure centrale pour la journalisation et le traçage sur l'AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace p. 13. Les applications et les démons de plateforme créent des messages de journalisation de manière flexible via des flux de données à sûreté de typage ou via des appels de fonction modélisés hautement efficaces avec un surcoût de contrôle minimal [SWS_LOG_00204]. Le filtrage des messages s'effectue via des niveaux de détail configurables par contexte, tandis que le réacheminement a lieu vers le backend DLT, les outils ARTI ou la console locale [SWS_LOG_00021].

plus ›

Le cluster fonctionnel Log and Trace (ara::log) représente l'infrastructure de base universelle pour la journalisation structurée, les sorties de diagnostic et le traçage proche du matériel dans l'AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace p. 13. Chaque instance de Logger représente un contexte propre au sein d'un processus et s'enregistre automatiquement auprès du backend de journalisation central lors de sa création EXP SWArchitecture p. 57. Outre les applications, des services de plateforme fondamentaux tels que Execution Management, Platform Health Management et Persistency intègrent également de manière obligatoire l'interface Logger pour la documentation du fonctionnement AUTOSAR AP EXP SWArchitecture p. 58.

Diagramme de contexte : intégration du cluster Log and Trace comme infrastructure centrale de journalisation et de traçage pour les applications adaptatives et les clusters fonctionnels de plateforme. Sources : AUTOSAR AP SWS LogAndTrace p. 13, AUTOSAR AP EXP SWArchitecture p. 58, SWS LogAndTrace p. 21, AUTOSAR AP SWS OperatingSystemInterface p. 21

Le module fait la distinction entre deux formes fondamentales d'interaction :

• Journalisation non modélisée : un patron Fluent Builder génère, via des méthodes liées au niveau de gravité (telles que LogInfo() ou LogError()), un objet temporaire LogStream qui concatène de manière sûre au niveau des types des types scalaires, des chaînes de caractères, des codes d'erreur et des modificateurs de format, et transmet le tampon au plus tard dans le destructeur ou via Flush() [SWS_LOG_00067], [SWS_LOG_00039], [SWS_LOG_00262].
• Journalisation modélisée : via l'interface à appel unique Logger::Log(id, args...), des messages préalablement déclarés dans le manifeste sont émis, ce qui permet un filtrage hautement efficace sans instanciation d'objets lorsque le seuil est inactif [SWS_LOG_00204], PlatformDesign p. 74.

Diagramme de séquence : déroulement de la journalisation par flux non modélisée via LogStream jusqu'à la transmission du tampon au backend de journalisation. Sources : [SWS_LOG_00067], [SWS_LOG_00040], [SWS_LOG_00039], [SWS_LOG_00262], PlatformDesign p. 74

Afin d'éviter tout temps de calcul inutile, le niveau de notification actif peut être vérifié au préalable au moyen de IsEnabled(logLevel) ou ajusté au moment de l'exécution via SetThreshold(threshold) [SWS_LOG_00070], [SWS_LOG_00255]. Outre le réacheminement vers des canaux DLT sur Ethernet ou vers des outils ARTI, la console sert de solution de secours en cas d'absence de configuration de modèle [SWS_LOG_00021], tandis que l'état de connexion de diagnostic externe peut être surveillé de manière asynchrone via RegisterConnectionStateHandler [SWS_LOG_00098], [SWS_LOG_00205].

plus ›

Architecture système et rôle fonctionnel de Log and Trace

Le cluster fonctionnel Log and Trace (ara::log) forme le sous-système central et transversal pour l'acquisition, le réacheminement et le filtrage standardisés des messages de diagnostic, de traçage et de journalisation sur l'AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace p. 13. L'interface de programmation Logger fournit l'API de plateforme C++ unifiée, qui est consommée comme infrastructure de base aussi bien par des processus spécifiques à l'application (Adaptive Applications) que par les clusters fonctionnels de plateforme fondamentaux AUTOSAR AP EXP SWArchitecture p. 58. Parmi ces démons système consommateurs figurent notamment Execution Management pour la documentation du cycle de vie des processus AUTOSAR AP EXP SWArchitecture p. 50, Platform Health Management pour la surveillance d'état AUTOSAR AP SWS PlatformHealthManagement p. 16, Time Synchronization pour des références temporelles de haute précision AUTOSAR AP SWS TimeSynchronization p. 17 ainsi qu'Update and Configuration Management pendant les mises à jour logicielles AUTOSAR AP EXP SWArchitecture p. 141.

D'un point de vue architectural, chaque instance de logger encapsule un contexte unique (Context ID) au sein d'un domaine d'application ou de processus, ce contexte s'enregistrant automatiquement auprès du backend de journalisation lors de sa création et étant automatiquement désenregistré lors de l'arrêt de l'application EXP SWArchitecture p. 57. Le backend de journalisation achemine les messages formatés vers des canaux de sortie configurés (par ex. des puits de protocole DLT sur Ethernet selon le manifeste de machine) ou vers des tampons locaux, avec un repli par défaut sur la console du système d'exploitation en cas d'absence de modèle de déploiement [SWS_LOG_00021], SWS LogAndTrace p. 21. En outre, une architecture d'adaptateur découplée permet au système d'exploitation (POSIX/OS) de fournir des métriques internes de noyau et d'ordonnancement via l'AUTOSAR Run-Time Interface (ARTI) de manière synchronisée avec les messages de ara::log AUTOSAR AP SWS OperatingSystemInterface p. 21.

Diagramme de contexte : intégration du cluster Log and Trace comme infrastructure centrale de journalisation et de traçage pour les applications adaptatives et les clusters fonctionnels de plateforme. Sources : AUTOSAR AP SWS LogAndTrace p. 13, AUTOSAR AP EXP SWArchitecture p. 58, SWS LogAndTrace p. 21, AUTOSAR AP SWS OperatingSystemInterface p. 21

Instanciation, gestion de contexte et contrôle des seuils

La mise à disposition d'un contexte de logger s'effectue via les fonctions de fabrique ara::log::CreateLogger, étant donné que le constructeur par défaut de la classe Logger est supprimé [SWS_LOG_00259]. Les applications peuvent instancier des loggers soit par programmation en indiquant un identifiant de contexte (ctxId), une description (ctxDescription) et optionnellement un niveau de journalisation par défaut [SWS_LOG_00021], [SWS_LOG_00263], soit par dérivation basée sur une instance via un élément de modèle au moyen de ara::core::InstanceSpecifier [SWS_LOG_00256]. Le destructeur de Logger prend en charge le désenregistrement de manière thread-safe [SWS_LOG_00260].

La granularité et la priorité des messages sont représentées de façon hiérarchique par l'énumération LogLevel : kFatal (erreur système non récupérable), kError (erreur avec dégradation fonctionnelle), kWarn (avertissement en cas de comportement nominal compromis), kInfo (information générale de fonctionnement), kDebug (diagnostic détaillé) et kVerbose (traçage détaillé) [SWS_LOG_00018], ManifestSpecification p. 416. Afin d'optimiser l'exécution, les préparations de données de journalisation exigeantes en calcul peuvent être évitées en vérifiant au préalable, via la requête IsEnabled(logLevel), si le niveau de journalisation concerné est actuellement actif sur le contexte [SWS_LOG_00070]. Le seuil de notification actif d'une instance de logger peut, si nécessaire, être adapté dynamiquement au moment de l'exécution via SetThreshold(threshold) [SWS_LOG_00255].

Journalisation non modélisée et composition de messages basée sur les flux

Pour les messages non modélisés, ara::log fournit une interface fluide inspirée du patron de conception Builder PlatformDesign p. 74. Le point d'entrée s'effectue via des fonctions membres spécifiques au niveau de gravité de l'instance Logger, à savoir LogFatal(), LogError(), LogWarn(), LogInfo(), LogDebug() et LogVerbose(), ou via WithLevel(logLevel), qui renvoient un objet temporaire et léger LogStream [SWS_LOG_00064], [SWS_LOG_00065], [SWS_LOG_00066], [SWS_LOG_00067], [SWS_LOG_00068], [SWS_LOG_00069], [SWS_LOG_00131]. Les données sont ensuite ajoutées de manière concaténée au tampon de messages interne via l'opérateur d'insertion de flux à sûreté de typage (operator<<) [SWS_LOG_00040].

L'interface de flux prend en charge un large éventail de types natifs C++ et AUTOSAR sans erreurs de formatage manuel :

• Des types entiers (signés et non signés de 8 à 64 bits) ainsi que des valeurs booléennes [SWS_LOG_00040], [SWS_LOG_00041], [SWS_LOG_00042], [SWS_LOG_00043], [SWS_LOG_00044], [SWS_LOG_00045], [SWS_LOG_00046], [SWS_LOG_00047], [SWS_LOG_00048].
• Des types à virgule flottante en simple et double précision (float, double) [SWS_LOG_00049], [SWS_LOG_00050].
• Des chaînes de caractères UTF-8 terminées par zéro et ara::core::StringView [SWS_LOG_00051], [SWS_LOG_00062].
• Des types spécifiques de la plateforme tels que LogLevel sous forme de texte [SWS_LOG_00063], des objets d'erreur ara::core::ErrorCode [SWS_LOG_00124], des durées std::chrono::duration [SWS_LOG_00125], des références de modèle ara::core::InstanceSpecifier [SWS_LOG_00126], des pointeurs bruts [SWS_LOG_00127] et des séquences d'octets via ara::core::Span<const ara::core::Byte> [SWS_LOG_00128].

Les métadonnées et les formatages peuvent être contrôlés avec précision : l'origine dans le code source est saisie via WithLocation(file, line) [SWS_LOG_00129], WithTag(tag) ajoute des mots-clés fonctionnels [SWS_LOG_00132], et WithPrivacy(value) définit un niveau de confidentialité via les 8 bits de poids faible [SWS_LOG_00258]. Les arguments formatés avec nom et unité physique sont encapsulés via le modèle utilitaire Arg [SWS_LOG_00201], [SWS_LOG_00203], avec l'aide des utilitaires de formatage Dflt, Hex, Dec, Oct, Bin, DecFloat, EngFloat, HexFloat et AutoFloat issus de l'énumération Fmt [SWS_LOG_00206], [SWS_LOG_00208], [SWS_LOG_00209], [SWS_LOG_00211], [SWS_LOG_00217], [SWS_LOG_00225], [SWS_LOG_00226].

En ce qui concerne le cycle de vie, LogStream est un objet déplaçable uniquement (move-only) : le constructeur de copie et l'opérateur d'assignation par copie sont supprimés [SWS_LOG_00174], [SWS_LOG_00175], tandis que le constructeur de déplacement est déclaré pour prendre en charge la Return Value Optimization (RVO) [SWS_LOG_00176] ; l'opérateur d'assignation par déplacement est supprimé [SWS_LOG_00177]. Le contenu du tampon est envoyé automatiquement au framework de journalisation via le destructeur ~LogStream() lors de la sortie de la portée [SWS_LOG_00262]. Si un objet LogStream doit être utilisé successivement pour plusieurs messages au sein de la même portée, la transmission du tampon doit être explicitement déclenchée via Flush(), ce qui initialise un flux de messages vierge [SWS_LOG_00039]. Interprétation : après l'appel de Flush(), la gestion interne du tampon de LogStream devrait vider et réinitialiser le tampon pour les opérateurs de flux ultérieurs au sein de la même portée, sans qu'une destruction de l'identité de l'objet ne soit requise. Question (ouverte)

Diagramme de séquence : déroulement de la journalisation par flux non modélisée via LogStream jusqu'à la transmission du tampon au backend de journalisation. Sources : [SWS_LOG_00067], [SWS_LOG_00040], [SWS_LOG_00039], [SWS_LOG_00262], PlatformDesign p. 74

Journalisation modélisée et embranchement vers le traçage ARTI

Contrairement à la construction progressive des messages non modélisés, ara::log définit pour les messages modélisés dans le manifeste une interface à appel unique hautement efficace via Logger::Log(id, args...) ainsi que Logger::LogWith(attrs, msgId, params...) [SWS_LOG_00204], [SWS_LOG_00133]. Tous les arguments sont transmis en un seul appel de fonction, ce qui réduit au minimum le surcoût à l'exécution en cas de messages supprimés : immédiatement après la transmission des paramètres, une unique condition vérifie le seuil et retourne immédiatement si le niveau de journalisation configuré n'est pas atteint PlatformDesign p. 74.

Au sein de l'appel de Log, le chemin de traitement se divise : outre le chemin classique de sérialisation DLT (buildDltMessage(), filtrage via masque de log et transmission au collecteur), il existe un chemin dédié pour le traçage au plus près du matériel via l'AUTOSAR Run-Time Interface (ARTI) au moyen de TraceArti(msg_id, params...) [SWS_LOG_20000], AUTOSAR AP SWS LogAndTrace p. 42. Le transfert vers TraceArti est vraisemblablement résolu au moment de la compilation par des spécialisations statiques de templates, afin de garantir le surcoût minimal requis à l'exécution. Le backend ARTI filtre selon ses propres critères en se basant sur le MsgId et contourne totalement la mise en mémoire tampon DLT, ce qui permet un traçage critique en temps réel sans perturber le sous-système de journalisation régulier AUTOSAR AP SWS LogAndTrace p. 42.

Diagramme d'activité : flux de contrôle et de filtrage lors de l'envoi de messages modélisés entre le backend DLT et le traçage ARTI. Sources : [SWS_LOG_00204], [SWS_LOG_20000], AUTOSAR AP SWS LogAndTrace p. 42, PlatformDesign p. 74

Surveillance des connexions client et intégration au diagnostic

Log and Trace ne fournit pas seulement des canaux de sortie locaux, mais surveille également l'état des clients de diagnostic externes (par ex. DLT Viewer sur Ethernet), représenté par l'énumération ClientState : kUnknown (-1, backend DLT pas encore prêt), kNotConnected (aucun client distant détecté) et kConnected (connexion à un client externe active) [SWS_LOG_00098]. Cela permet aux applications d'assujettir un traçage coûteux à la présence physique d'un outil d'analyse.

Pour le suivi d'état asynchrone, les applications enregistrent une fonction de rappel via ara::log::RegisterConnectionStateHandler en utilisant l'alias de fonction ConnectionStateHandler = std::function<void(ClientState)> [SWS_LOG_00205], [SWS_LOG_00265]. Le framework de journalisation ne prend en charge ici qu'un seul enregistrement de gestionnaire actif : un nouvel appel de RegisterConnectionStateHandler écrase sans restriction un rappel précédemment installé [SWS_LOG_00205].

Diagramme d'états : transitions d'état du client externe selon ClientState. Sources : [SWS_LOG_00098], [SWS_LOG_00205], [SWS_LOG_00265]

Comportement en cas d'erreur

Le module applique la sécurité fonctionnelle et la robustesse principalement par des vérifications statiques de types à la compilation et de strictes garanties d'exception :

• Erreurs à la compilation (ill-formed) : l'appel de Logger::Log(id, args...) est non conforme (ill-formed) si les arguments transmis ne correspondent pas exactement à la signature de message déclarée dans le manifeste [SWS_LOG_00204]. De même, l'utilisation de Arg() avec des types qui ne sont ni arithmétiques, ni booléens, ni convertibles en StringView ou Span<const Byte> entraîne un échec de la compilation [SWS_LOG_00201]. La fonction WithPrivacy(value) impose en outre que le type de paramètre soit un type entier ou une énumération [SWS_LOG_00258].
• Interdictions de construction et d'affectation : afin d'exclure toute duplication involontaire de mémoire tampon ou tout conflit de ressources, le constructeur de copie et l'opérateur d'affectation par copie de LogStream ainsi que l'opérateur d'affectation par déplacement sont explicitement supprimés [SWS_LOG_00174], [SWS_LOG_00175], [SWS_LOG_00177].
• Intégrité à l'exécution lors de l'instanciation : si la résolution de l'ara::core::InstanceSpecifier dans le modèle de machine ou d'application échoue lors de CreateLogger(is) ou si celui-ci ne référence pas un élément de modèle valide, le système signale une InstanceSpecifierMappingIntegrityViolation [SWS_LOG_00256].
• Collecteurs de secours à tolérance de panne : si, à l'exécution, aucun modèle de déploiement ou aucune connectivité réseau vers le service DLT n'est disponible, le framework bascule automatiquement sur la console locale comme collecteur de sortie par défaut, de sorte qu'aucune information de diagnostic ne soit perdue silencieusement [SWS_LOG_00021], [SWS_LOG_00263]. Lors de l'émission d'un core::ErrorCode sur la console, l'affichage s'effectue via le nom de domaine et la valeur d'erreur numérique [SWS_LOG_00124].
• Sécurité vis-à-vis des exceptions : l'ensemble des opérateurs de flux, des interrogations de seuil et le destructeur ~LogStream() sont déclarés comme noexcept afin de garantir que la journalisation ne propage à aucun moment d'exceptions non gérées vers les blocs fonctionnels applicatifs [SWS_LOG_00040], [SWS_LOG_00070], [SWS_LOG_00262] ; le destructeur ~Logger() n'est en revanche formellement pas spécifié comme noexcept [SWS_LOG_00260].

Preuves détaillées supplémentaires

L'architecture et le comportement du module Log and Trace sont ancrés dans les points de référence suivants de la spécification AUTOSAR :

• Spécification d'interface de cluster : les signatures C++ normatives, les opérateurs de flux et les méthodes de contexte de Logger et LogStream sont définis dans la spécification de Log and Trace [SWS_LOG_00021], [SWS_LOG_00039], [SWS_LOG_00064], [SWS_LOG_00204], AUTOSAR AP SWS LogAndTrace p. 13.
• Conception de la plateforme et performances : la comparaison architecturale entre le patron de conception monteur (Builder) et l'appel direct unique hautement efficace pour les messages modélisés est exposée dans le Platform Design PlatformDesign p. 74.
• Dépendances à l'échelle de la plateforme : l'utilisation obligatoire de l'interface Logger par les clusters de plateforme fonctionnels est répertoriée dans les documents d'architecture respectifs AUTOSAR AP EXP SWArchitecture p. 58, AUTOSAR AP EXP SWArchitecture p. 50, AUTOSAR AP SWS PlatformHealthManagement p. 16.
• Modèle de manifeste et de déploiement : la configuration des canaux de log DLT, des associations de processus et des points de terminaison machine est régie dans la spécification du manifeste SWS LogAndTrace p. 21, ManifestSpecification p. 416.
• Adaptateurs de système d'exploitation et ARTI : l'intégration des mémoires tampon de trace natives du système d'exploitation à ara::log et l'acquisition au plus près du matériel via TraceArti sont spécifiées dans l'architecture OSI et de traçage [SWS_LOG_20000], AUTOSAR AP SWS OperatingSystemInterface p. 21, AUTOSAR AP SWS LogAndTrace p. 42.