модуль ara::log — Log and Trace

Функциональный кластер Log and Trace предоставляет центральную инфраструктуру для протоколирования и трассировки на платформе AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace с. 13. Приложения и сервисные демоны платформы гибко создают сообщения журнала через типобезопасные потоки данных или через высокоэффективные смоделированные вызовы функций с минимальными накладными расходами на проверку [SWS_LOG_00204]. Фильтрация сообщений выполняется по настраиваемым уровням детализации для каждого контекста, в то время как пересылка осуществляется в бэкенд DLT, инструменты ARTI или в локальную консоль [SWS_LOG_00021].

больше ›

Функциональный кластер Log and Trace (ara::log) представляет собой универсальную базовую инфраструктуру для структурированного протоколирования, диагностического вывода и низкоуровневой трассировки в AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace с. 13. Каждый экземпляр Logger представляет собственный контекст внутри процесса и при своем создании автоматически регистрируется в центральном бэкенде логирования EXP SWArchitecture с. 57. Помимо приложений, базовые сервисы платформы, такие как Execution Management, Platform Health Management и Persistency, также обязательно подключают интерфейс Logger для документирования работы AUTOSAR AP EXP SWArchitecture с. 58.

Контекстная диаграмма: интеграция кластера Log and Trace в качестве центральной инфраструктуры протоколирования и трассировки для адаптивных приложений и функциональных кластеров платформы. Источники: AUTOSAR AP SWS LogAndTrace с. 13, AUTOSAR AP EXP SWArchitecture с. 58, SWS LogAndTrace с. 21, AUTOSAR AP SWS OperatingSystemInterface с. 21

Модуль различает две основные формы взаимодействия:

• Немоделированное протоколирование: шаблон Fluent Builder создает с помощью привязанных к уровню важности методов (таких как LogInfo() или LogError()) временный объект LogStream, который типобезопасно объединяет в цепочку скалярные типы, строки, коды ошибок и модификаторы формата и передает буфер не позднее чем в деструкторе или через Flush() [SWS_LOG_00067], [SWS_LOG_00039], [SWS_LOG_00262].
• Моделированное протоколирование: через интерфейс одиночного вызова Logger::Log(id, args...) отправляются сообщения, предварительно объявленные в манифесте, что при неактивном пороговом значении обеспечивает высокоэффективную фильтрацию без создания экземпляра объекта [SWS_LOG_00204], PlatformDesign с. 74.

Диаграмма последовательности: процесс немоделированного потокового протоколирования через LogStream вплоть до передачи буфера в бэкенд логирования. Источники: [SWS_LOG_00067], [SWS_LOG_00040], [SWS_LOG_00039], [SWS_LOG_00262], PlatformDesign с. 74

Во избежание лишнего процессорного времени активный уровень сообщений можно предварительно проверить с помощью IsEnabled(logLevel) или настроить во время выполнения через SetThreshold(threshold) [SWS_LOG_00070], [SWS_LOG_00255]. Помимо пересылки в каналы DLT через Ethernet или в инструменты ARTI, при отсутствии конфигурации модели в качестве аварийного варианта выступает консоль [SWS_LOG_00021], в то время как статус внешнего диагностического соединения может асинхронно контролироваться через RegisterConnectionStateHandler [SWS_LOG_00098], [SWS_LOG_00205].

больше ›

Архитектура системы и функциональная роль Log and Trace

Функциональный кластер Log and Trace (ara::log) образует центральную сквозную подсистему для стандартизированного сбора, пересылки и фильтрации диагностических сообщений, трассировки и протоколирования на платформе AUTOSAR Adaptive Platform AUTOSAR AP SWS LogAndTrace с. 13. Программный интерфейс Logger предоставляет унифицированный C++-API платформы, который используется как прикладными процессами (Adaptive Applications), так и базовыми функциональными кластерами платформы в качестве базовой инфраструктуры AUTOSAR AP EXP SWArchitecture с. 58. К этим использующим инфраструктуру системным демонам относятся, в частности, Execution Management для документирования жизненного цикла процессов AUTOSAR AP EXP SWArchitecture с. 50, Platform Health Management для мониторинга состояния AUTOSAR AP SWS PlatformHealthManagement с. 16, Time Synchronization для высокоточных временных привязок AUTOSAR AP SWS TimeSynchronization с. 17, а также Update and Configuration Management во время обновлений программного обеспечения AUTOSAR AP EXP SWArchitecture с. 141.

С точки зрения архитектуры каждый экземпляр логгера инкапсулирует уникальный контекст (Context ID) в пределах области приложения или процесса, при этом данный контекст автоматически регистрируется в бэкенде логирования при создании и автоматически разрегистрируется при завершении работы приложения EXP SWArchitecture с. 57. Бэкенд логирования пересылает отформатированные сообщения в сконфигурированные каналы вывода (например, приемники протокола DLT через Ethernet согласно манифесту машины) или в локальные буферы, при этом при отсутствии модели развертывания по умолчанию задействуется консоль операционной системы [SWS_LOG_00021], SWS LogAndTrace с. 21. Кроме того, декомпозированная архитектура адаптеров позволяет операционной системе (POSIX/OS) предоставлять внутренние метрики ядра и планирования через AUTOSAR Run-Time Interface (ARTI) синхронизированно с сообщениями ara::log AUTOSAR AP SWS OperatingSystemInterface с. 21.

Контекстная диаграмма: интеграция кластера Log and Trace в качестве центральной инфраструктуры протоколирования и трассировки для адаптивных приложений и функциональных кластеров платформы. Источники: AUTOSAR AP SWS LogAndTrace с. 13, AUTOSAR AP EXP SWArchitecture с. 58, SWS LogAndTrace с. 21, AUTOSAR AP SWS OperatingSystemInterface с. 21

Инстанцирование, управление контекстами и контроль пороговых значений

Предоставление контекста логгера осуществляется через фабричные функции ara::log::CreateLogger, поскольку конструктор по умолчанию класса Logger удален [SWS_LOG_00259]. Приложения могут создавать экземпляры логгеров либо программно с указанием ID контекста (ctxId), описания (ctxDescription) и опционально стандартного уровня логирования [SWS_LOG_00021], [SWS_LOG_00263], либо инстанцировать на основе модели через элемент модели с помощью ara::core::InstanceSpecifier [SWS_LOG_00256]. Деструктор Logger выполняет дерегистрацию потокобезопасным образом [SWS_LOG_00260].

Детализация и приоритет сообщений иерархически отображаются перечислением LogLevel: kFatal (неустранимая системная ошибка), kError (ошибка с нарушением функциональности), kWarn (предупреждение при риске нарушения требуемого поведения), kInfo (общая эксплуатационная информация), kDebug (подробная диагностика) и kVerbose (детальная трассировка) [SWS_LOG_00018], ManifestSpecification с. 416. Для оптимизации времени выполнения можно избежать ресурсоемкой подготовки данных протокола, предварительно проверив с помощью запроса IsEnabled(logLevel), активен ли в данный момент соответствующий уровень логирования для этого контекста [SWS_LOG_00070]. Активное пороговое значение сообщений экземпляра логгера при необходимости можно динамически настраивать во время выполнения через SetThreshold(threshold) [SWS_LOG_00255].

Немоделированное протоколирование и потоковая композиция сообщений

Для немоделированных сообщений ara::log предоставляет интерфейс Fluent Interface, основанный на шаблоне проектирования Builder PlatformDesign с. 74. Точкой входа служат функции-члены экземпляра Logger, специфичные для уровня важности, а именно LogFatal(), LogError(), LogWarn(), LogInfo(), LogDebug() и LogVerbose(), или WithLevel(logLevel), которые возвращают временный легковесный объект LogStream [SWS_LOG_00064], [SWS_LOG_00065], [SWS_LOG_00066], [SWS_LOG_00067], [SWS_LOG_00068], [SWS_LOG_00069], [SWS_LOG_00131]. Затем данные последовательно добавляются во внутренний буфер сообщений через типобезопасный оператор вставки в поток (operator<<) [SWS_LOG_00040].

Потоковый интерфейс поддерживает широкий спектр нативных типов C++ и AUTOSAR без ошибок ручного форматирования:

• Целочисленные типы (знаковые и беззнаковые от 8 до 64 бит), а также логические значения [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].
• Типы с плавающей запятой одинарной и двойной точности (float, double) [SWS_LOG_00049], [SWS_LOG_00050].
• Строки UTF-8 с нулевым символом в конце и ara::core::StringView [SWS_LOG_00051], [SWS_LOG_00062].
• Специфические типы платформы, такие как LogLevel в текстовой форме [SWS_LOG_00063], объекты ошибок ara::core::ErrorCode [SWS_LOG_00124], интервалы времени std::chrono::duration [SWS_LOG_00125], ссылки на модель ara::core::InstanceSpecifier [SWS_LOG_00126], необработанные указатели [SWS_LOG_00127] и байтовые последовательности через ara::core::Span<const ara::core::Byte> [SWS_LOG_00128].

Метаданными и форматированием можно управлять с высокой точностью: через WithLocation(file, line) регистрируется источник в исходном коде [SWS_LOG_00129], WithTag(tag) добавляет функциональные ключевые слова [SWS_LOG_00132], а WithPrivacy(value) задает уровень конфиденциальности через младшие 8 бит [SWS_LOG_00258]. Форматированные аргументы с именем и физической единицей измерения инкапсулируются через вспомогательный шаблон Arg [SWS_LOG_00201], [SWS_LOG_00203], поддерживаемый средствами форматирования Dflt, Hex, Dec, Oct, Bin, DecFloat, EngFloat, HexFloat и AutoFloat из перечисления Fmt [SWS_LOG_00206], [SWS_LOG_00208], [SWS_LOG_00209], [SWS_LOG_00211], [SWS_LOG_00217], [SWS_LOG_00225], [SWS_LOG_00226].

С точки зрения жизненного цикла LogStream является объектом только для перемещения (move-only): конструктор копирования и оператор присваивания с копированием удалены [SWS_LOG_00174], [SWS_LOG_00175], тогда как конструктор перемещения объявлен для поддержки оптимизации возвращаемого значения (RVO) [SWS_LOG_00176]; оператор присваивания с перемещением удален [SWS_LOG_00177]. Содержимое буфера автоматически отправляется в каркас логирования через деструктор ~LogStream() при выходе из области видимости [SWS_LOG_00262]. Если объект LogStream должен использоваться в пределах одной и той же области видимости для нескольких сообщений подряд, передачу буфера необходимо явно запускать через Flush(), благодаря чему инициализируется новый поток сообщений [SWS_LOG_00039]. Интерпретация: внутреннее управление буфером LogStream после вызова Flush(), вероятно, очищает и повторно инициализирует буфер для последующих потоковых операторов в той же области видимости без необходимости разрушения идентичности объекта. Вопрос (открытый)

Диаграмма последовательности: процесс немоделированного потокового протоколирования через LogStream вплоть до передачи буфера в бэкенд логирования. Источники: [SWS_LOG_00067], [SWS_LOG_00040], [SWS_LOG_00039], [SWS_LOG_00262], PlatformDesign с. 74

Моделированное протоколирование и ветвление в сторону трассировки ARTI

В отличие от поэтапного формирования немоделированных сообщений, ara::log определяет для смоделированных в манифесте сообщений высокоэффективный интерфейс одиночного вызова через Logger::Log(id, args...), а также Logger::LogWith(attrs, msgId, params...) [SWS_LOG_00204], [SWS_LOG_00133]. Все аргументы передаются за один вызов функции, благодаря чему накладные расходы времени выполнения в случае подавленных сообщений сводятся к минимуму: сразу после передачи параметров одно условие проверяет пороговое значение и немедленно возвращает управление, если сконфигурированный уровень логирования не достигнут PlatformDesign с. 74.

Внутри вызова Log путь обработки разделяется: наряду с классическим путем сериализации DLT (buildDltMessage(), фильтрация через маску логирования и передача в приемник) существует выделенный путь для низкоуровневой трассировки через AUTOSAR Run-Time Interface (ARTI) с помощью TraceArti(msg_id, params...) [SWS_LOG_20000], AUTOSAR AP SWS LogAndTrace с. 42. Предположительно, перенаправление в TraceArti разрешается через статические специализации шаблонов во время компиляции, чтобы гарантировать требуемые минимальные накладные расходы времени выполнения. Вопрос (открытый) Бэкенд ARTI фильтрует по собственным критериям на основе MsgId и полностью обходит буферизацию DLT, что обеспечивает критически важную для реального времени трассировку без нарушения работы регулярной подсистемы логирования AUTOSAR AP SWS LogAndTrace с. 42.

Диаграмма деятельности: поток управления и фильтрации при отправке смоделированных сообщений между бэкендом DLT и трассировкой ARTI. Источники: [SWS_LOG_00204], [SWS_LOG_20000], AUTOSAR AP SWS LogAndTrace с. 42, PlatformDesign с. 74

Мониторинг клиентских соединений и подключение диагностики

Log and Trace не только предоставляет локальные каналы вывода, но и отслеживает состояние внешних диагностических клиентов (например, DLT-Viewer через Ethernet), представленное перечислением ClientState: kUnknown (-1, бэкенд DLT еще не готов), kNotConnected (удаленный клиент не обнаружен) и kConnected (соединение с внешним клиентом активно) [SWS_LOG_00098]. Это позволяет приложениям привязывать ресурсоемкую трассировку к физическому присутствию инструмента анализа.

Для асинхронного отслеживания состояния приложения регистрируют функцию обратного вызова через ara::log::RegisterConnectionStateHandler с использованием псевдонима функции ConnectionStateHandler = std::function<void(ClientState)> [SWS_LOG_00205], [SWS_LOG_00265]. При этом каркас логирования поддерживает ровно одну активную регистрацию обработчика: повторный вызов RegisterConnectionStateHandler полностью перезаписывает ранее установленный callback [SWS_LOG_00205].

Диаграмма состояний: переходы состояний внешнего клиента согласно ClientState. Источники: [SWS_LOG_00098], [SWS_LOG_00205], [SWS_LOG_00265]

Поведение при ошибке

Модуль обеспечивает функциональную безопасность и надежность прежде всего за счет статических проверок типов во время компиляции и строгих гарантий безопасности исключений:

• Ошибки времени компиляции (ill-formed): вызов Logger::Log(id, args...) является недопустимым (ill-formed), если переданные аргументы не совпадают точно с сигнатурой сообщения, объявленной в манифесте [SWS_LOG_00204]. Точно так же использование Arg() с типами, которые не являются ни арифметическими, ни логическими, ни преобразуемыми в StringView или Span<const Byte>, приводит к сбою компиляции [SWS_LOG_00201]. Функция WithPrivacy(value) дополнительно требует, чтобы тип параметра был целочисленным типом или перечислением [SWS_LOG_00258].
• Запреты на конструирование и присваивание: во избежание непреднамеренного дублирования буферов или конфликтов ресурсов конструктор копирования и оператор присваивания с копированием LogStream, а также оператор присваивания с перемещением явно удалены [SWS_LOG_00174], [SWS_LOG_00175], [SWS_LOG_00177].
• Целостность во время выполнения при инстанцировании: если разрешение ara::core::InstanceSpecifier в модели машины или приложения при CreateLogger(is) завершается неудачно или он не указывает на допустимый элемент модели, система сообщает об InstanceSpecifierMappingIntegrityViolation [SWS_LOG_00256].
• Отказоустойчивые резервные приемники: если во время выполнения отсутствует модель развертывания или сетевое подключение к сервису DLT, каркас автоматически переключается на локальную консоль в качестве стандартного приемника вывода, благодаря чему диагностическая информация не теряется незаметно [SWS_LOG_00021], [SWS_LOG_00263]. При выводе core::ErrorCode на консоль отображение осуществляется через имя домена и числовое значение ошибки [SWS_LOG_00124].
• Безопасность исключений: все потоковые операторы, запросы пороговых значений и деструктор ~LogStream() объявлены как noexcept, чтобы гарантировать, что протоколирование ни в какой момент времени не передаст необработанные исключения в вызывающие функциональные блоки [SWS_LOG_00040], [SWS_LOG_00070], [SWS_LOG_00262]; деструктор ~Logger(), напротив, формально не специфицирован как noexcept [SWS_LOG_00260].

Дальнейшие подробные доказательства

Архитектура и поведение модуля Log and Trace закреплены в следующих разделах спецификации AUTOSAR:

• Спецификация интерфейсов кластера: нормативные C++-сигнатуры, потоковые операторы и методы контекста Logger и LogStream определены в спецификации Log and Trace [SWS_LOG_00021], [SWS_LOG_00039], [SWS_LOG_00064], [SWS_LOG_00204], AUTOSAR AP SWS LogAndTrace с. 13.
• Дизайн платформы и производительность: архитектурное сравнение шаблона Builder и высокоэффективного одиночного вызова для смоделированных сообщений изложено в Platform Design PlatformDesign с. 74.
• Общеплатформенные зависимости: обязательное использование интерфейса Logger функциональными кластерами платформы регламентируется в соответствующих архитектурных документах AUTOSAR AP EXP SWArchitecture с. 58, AUTOSAR AP EXP SWArchitecture с. 50, AUTOSAR AP SWS PlatformHealthManagement с. 16.
• Модель манифеста и развертывания: конфигурация каналов логирования DLT, привязок процессов и конечных точек машины определена в спецификации манифеста SWS LogAndTrace с. 21, ManifestSpecification с. 416.
• Адаптеры операционной системы и ARTI: подключение нативных буферов трассировки операционной системы к ara::log и низкоуровневый сбор данных через TraceArti специфицированы в архитектуре OSI и трассировки [SWS_LOG_20000], AUTOSAR AP SWS OperatingSystemInterface с. 21, AUTOSAR AP SWS LogAndTrace с. 42.