класс ara::diag::Indicator

Интерфейс служит для структурированного опроса и мониторинга диагностических индикаторов транспортного средства в рамках AUTOSAR Adaptive Platform. Приложения инстанцируют объект через смоделированный идентификатор и могут считывать текущее состояние с помощью асинхронного метода опроса [SWS_DM_00744]. Кроме того, можно зарегистрировать пользовательскую функцию обратного вызова, которая получает обновления состояния непосредственно при изменениях [SWS_DM_00745]. Важным граничным условием является то, что экземпляр строго привязан к порту, не подлежит копированию или перемещению и требует синхронизации от параллельных вызовов при регистрации и уничтожении.

больше ›

Контекст

Класс ara::diag::Indicator функционирует в модуле diag Adaptive Platform как центральное представление DiagnosticIndicatorInterface [SWS_DM_00742]. Его основная задача состоит в том, чтобы предоставить приложениям доступ к диагностическим индикаторам, таким как контрольные лампы или индикаторы функций (например, Malfunction Indicator Light, MIL).

Во взаимодействии в основном участвуют три компонента: использующее адаптивное приложение (такое как комбинация приборов или служба HMI), экземпляр ara::diag::Indicator как локальная конечная точка интерфейса, а также демон Diagnostic Management (DM). Последний обрабатывает общесистемные диагностические события и состояния DTC стандарта UDS транспортного средства и предоставляет базовую диагностическую функциональность [SWS_DM_00744].

Контекстная диаграмма: партнеры по взаимодействию интерфейса ara::diag::Indicator между логикой приложения и демоном Diagnostic Management. Источники: [SWS_DM_00742], [SWS_DM_00744].

Жизненный цикл

Создание объекта ara::diag::Indicator выполняется явно путем передачи ara::core::InstanceSpecifier в конструктор [SWS_DM_00742]. Этот идентификатор привязывает объект к PortPrototype, определенному в модели проектирования, который обязательно должен быть типизирован как DiagnosticIndicatorInterface [SWS_DM_00742].

С точки зрения отношений владения и объектной семантики ara::diag::Indicator спроектирован как строго одиночный экземпляр: запрещены как копирование, так и перемещение. Соответственно, конструктор копирования [SWS_DM_01629], конструктор перемещения [SWS_DM_01630], оператор присваивания копированием [SWS_DM_01627] и оператор присваивания перемещением [SWS_DM_01628] объявлены удаленными (=delete).

Жизненный цикл завершается вызовом деструктора ~Indicator() [SWS_DM_00743]. В то время как конструктор и опрос состояния специфицированы как потокобезопасные [SWS_DM_00742], [SWS_DM_00744], деструктор не является потокобезопасным [SWS_DM_00743]. Поэтому вызывающее приложение должно гарантировать, что во время уничтожения больше не происходит параллельных вызовов методов или выполнения уведомлений (notifier).

Путь использования

После успешной инициализации класс поддерживает две взаимодополняющие модели использования для определения состояния индикатора:

• Управляемое событиями уведомление: через SetNotifier() может быть зарегистрирована функция обратного вызова типа IndicatorStatusTypeNotifier [SWS_DM_00745], [SWS_DM_02129]. Как только состояние индикатора изменяется, среда выполнения вызывает этот Notifier. Последовательный вызов SetNotifier() перезаписывает ранее зарегистрированный обработчик [SWS_DM_00745]. Поскольку SetNotifier() не является потокобезопасным, регистрация должна быть синхронизирована извне [SWS_DM_00745]. Предположительно, Notifier выполняется в контексте фонового потока Diagnostic Management, поэтому в нем не должно происходить длительных блокировок. Вопрос Q-c27898ecefb8006f (открытый)
• Целевой опрос: через GetIndicatorState() можно активно запросить текущее состояние в любой произвольный момент времени [SWS_DM_00744]. Метод является потокобезопасным и возвращает ara::core::Future<IndicatorStatusType> [SWS_DM_00744]. Интерпретация: асинхронное предоставление через Future указывает на то, что опрос внутри делегируется центральному демону Diagnostic Management через межпроцессное взаимодействие (IPC). Вопрос Q-61a650bd8ab7fc04 (открытый)

Диаграмма последовательности: типичный процесс инстанцирования, регистрации Notifier, опроса состояния и уничтожения объекта. Источники: [SWS_DM_00742], [SWS_DM_00744], [SWS_DM_00745], [SWS_DM_00743].

Сценарии ошибок

Условия ошибок могут возникать как на этапе инициализации, так и во время выполнения:

• Нарушения конфигурации при конструировании: конструктор сообщает о несоответствиях моделирования в форме определенных нарушений (Violations) [SWS_DM_00742]. К ним относятся InstanceSpecifierMappingIntegrityViolation (идентификатор не может быть разрешен или не ссылается на порт), PortInterfaceMappingViolation (целевой порт не типизирован с помощью DiagnosticIndicatorInterface), ProcessMappingViolation (отсутствует подходящий смоделированный процесс для экземпляра времени выполнения), а также InstanceSpecifierAlreadyInUseViolation (идентификатор уже используется другим экземпляром в процессе) [SWS_DM_00742].
• Сбой диагностических функций: если выполнение GetIndicatorState() завершается сбоем, через возвращенный объект Future передается код ошибки DiagErrc::kServiceNotAvailable [SWS_DM_00744]. Это происходит, когда базовые функции Diagnostic Management недоступны во время вызова [SWS_DM_00744].
• Конкурирующий доступ: поскольку SetNotifier() [SWS_DM_00745] и деструктор [SWS_DM_00743] не являются потокобезопасными, незащищенный параллельный доступ приводит к неопределенному поведению во время выполнения.