модуль ara::phm — Platform Health Management

Platform Health Management в качестве центрального демона контролирует функциональную безопасность и целостность времени выполнения приложений и сервисов платформы согласно AUTOSAR_AP_SWS_PlatformHealthManagement с. 15. Контролируемые сущности циклически или по событиям сообщают о своих контрольных точках в систему, которая анализирует дедлайны, циклы активности (alive-циклы) и логические потоки управления. При обнаружении ошибок модуль уведомляет State Management для запуска целевых действий по восстановлению через [SWS_PHM_01142]. Если восстановление не происходит или отказывают центральные инстанции, триггер сторожевого таймера принудительно переводит машину в безопасное состояние.

больше ›

Platform Health Management (PHM) представляет собой центральную фоновую службу AUTOSAR Adaptive Platform для обеспечения функциональной безопасности и целостности программного обеспечения согласно ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement с. 15. Он контролирует как прикладные процессы, так и процессы платформы с помощью детерминированных сообщений контрольных точек и страхует аппаратное обеспечение посредством циклических триггеров сторожевого таймера AUTOSAR_AP_SWS_PlatformHealthManagement с. 46.

Контекстная диаграмма: архитектурная интеграция демона PHM во взаимодействии с контролируемыми приложениями, State Management, Execution Management, сторожевым таймером и IdsM. Источники: AUTOSAR_AP_SWS_PlatformHealthManagement с. 46, AUTOSAR_AP_SWS_PlatformHealthManagement с. 15, AUTOSAR_AP_EXP_SWArchitecture с. 131.

Функциональный контроль опирается на интерфейс ara::phm::SupervisedEntity, через который процессы сообщают о контрольных точках с помощью ReportCheckpoint() ([SWS_PHM_01123], [SWS_PHM_01127]). PHM подразделяет верификацию на три вида контроля [SWS_PHM_01138]:

• Alive Supervision для циклического контроля частоты AUTOSAR_FO_ASWS_HealthMonitoring с. 22,
• Deadline Supervision для контроля максимальных сроков выполнения AUTOSAR_AP_SWS_PlatformHealthManagement с. 15,
• Logical Supervision для соблюдения определенных графов потока управления AUTOSAR_AP_SWS_PlatformHealthManagement с. 15.

Эти элементарные результаты агрегируются для каждой Function Group в объединенный статус GlobalSupervisionStatus ([SWS_PHM_01137], SWS_PlatformHealthManagement с. 39).

При обнаружении нарушений PHM делегирует устранение ошибок компоненту State Management через RecoveryHandler() интерфейса RecoveryAction после того, как тот сообщил о своей готовности к обслуживанию с помощью Offer() ([SWS_PHM_01142], [SWS_PHM_01143]). Если State Management не может устранить ошибку или выходят из строя сами центральные демоны, срабатывает эскалация безопасности: PHM инициирует немедленный аппаратный сброс через нативный WatchdogInterface с FireWatchdogReaction() ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture с. 220).

Диаграмма последовательности: эскалация ошибок в State Management через RecoveryHandler с ветвлением на срабатывание сторожевого таймера в случае сбоя. Источники: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture с. 234, AUTOSAR_AP_EXP_SWArchitecture с. 220, AUTOSAR_AP_EXP_SWArchitecture с. 220.

больше ›

Границы системы и функциональная интеграция Health Management

Platform Health Management (PHM) представляет собой центральную функциональную инстанцию в составе AUTOSAR Adaptive Platform для контроля целостности выполнения, доступности сервисов и функциональной безопасности по ISO 26262 AUTOSAR_AP_SWS_PlatformHealthManagement с. 15. В качестве автономной фоновой службы (на базе демона) модуль реализует детерминированную верификацию временных и логических потоков управления в критически важных для безопасности процессах AUTOSAR_AP_EXP_SWArchitecture с. 128. Границы системы охватывают три основные оси взаимодействия: прием сообщений о контрольных точках от контролируемых программных модулей, эскалацию ошибок в State Management и циклическую отправку сигналов активности на низкоуровневый сторожевой таймер AUTOSAR_AP_SWS_PlatformHealthManagement с. 46.

Обязанности по контролю не ограничиваются исключительно стандартными пользовательскими приложениями (Adaptive Applications). Напротив, базовые сервисы платформы, такие как Execution Management, State Management, Diagnostic Manager и синхронизация времени, также подлежат контролю со стороны PHM, выступая в роли контролируемых сущностей и передавая контрольные точки в Health Management AUTOSAR_AP_EXP_SWArchitecture с. 130. Для внутренних вспомогательных функций демон PHM опирается на интерфейсы Execution Management (ExecutionClient для сообщения о состоянии процесса) и подсистемы логирования (Logger из Log and Trace) AUTOSAR_AP_EXP_SWArchitecture с. 131.

Контекстная диаграмма: архитектурная интеграция демона PHM во взаимодействии с контролируемыми приложениями, State Management, Execution Management, сторожевым таймером и IdsM. Источники: AUTOSAR_AP_SWS_PlatformHealthManagement с. 46, AUTOSAR_AP_SWS_PlatformHealthManagement с. 15, AUTOSAR_AP_EXP_SWArchitecture с. 131.

Инструментирование и жизненный цикл контролируемых сущностей

Логическая единица контроля внутри процесса представлена интерфейсом ara::phm::SupervisedEntity [SWS_PHM_01123]. Инстанцирование выполняется явно с указанием типизированного идентификатора типа ara::core::InstanceSpecifier, который ссылается на сконфигурированный путь к порту в системном манифесте AUTOSAR_TPS_ManifestSpecification с. 141. Для защиты целостности экземпляра конструктор копирования и копирующий оператор присваивания удалены ([SWS_PHM_01212], [SWS_PHM_01213]); однако экземпляры разрешено перемещать ([SWS_PHM_01214], [SWS_PHM_01215]). При удалении деструктор освобождает сущность [SWS_PHM_01211].

Инструментированное программное обеспечение сообщает о достижении заданных точек программы с помощью синхронного вызова ReportCheckpoint() [SWS_PHM_01127]. В качестве параметра используется типизированное перечисление контрольных точек, генерируемое из заголовка интерфейса ([SWS_PHM_00424], [SWS_PHM_00425]). Демон PHM проверяет полномочия процесса при каждом сообщении; если метод вызывает процесс, не смоделированный в манифесте, фиксируется нарушение прав доступа [SWS_PHM_01127]. При критических для безопасности аномалиях PHM может перенаправить ошибку доступа в Intrusion Detection System Manager (IdsM) AUTOSAR_AP_EXP_SWArchitecture с. 236.

Контролем сущности во время выполнения можно управлять в зависимости от состояния: с помощью Enable() контроль активируется, если текущее состояние соответствующей Function Group позволяет это [SWS_PHM_01130]. С помощью Disable() контроль можно снова приостановить [SWS_PHM_01380]. Оба метода возвращают ara::core::Future<void> и сигнализируют об асинхронных ошибках предоставления, например PhmErrc::kServiceNotReady [SWS_PHM_01130].

Диаграмма последовательности: процесс передачи сообщения контрольной точки через SupervisedEntity с проверкой прав и контролем безопасности со стороны IdsM. Источники: [SWS_PHM_01127], AUTOSAR_AP_EXP_SWArchitecture с. 236.

Виды контроля и многоуровневая агрегация статусов

Platform Health Management различает три основных элементарных вида контроля ([SWS_PHM_01138], AUTOSAR_AP_EXP_SWArchitecture с. 128):

• Alive Supervision (kAliveSupervision): проверяет, отправляют ли циклические части программы сконфигурированное минимальное и максимальное количество сообщений контрольных точек в пределах определенных временных окон AUTOSAR_FO_ASWS_HealthMonitoring с. 22.
• Deadline Supervision (kDeadlineSupervision): контролирует длительность выполнения между двумя контрольными точками на предмет соблюдения сконфигурированных минимальных и максимальных сроков AUTOSAR_AP_SWS_PlatformHealthManagement с. 15.
• Logical Supervision (kLogicalSupervision): валидирует порядок выполнения на основе смоделированного графа переходов для выявления недопустимых переходов или ветвлений потока управления AUTOSAR_AP_SWS_PlatformHealthManagement с. 15.

Каждый отдельный контроль имеет собственный конечный автомат для своего элементарного статуса (ElementarySupervisionStatus) [SWS_PHM_01358]. При запуске PHM все элементарные конечные автоматы инициализируются в состоянии kDEACTIVATED, а счетчики ошибок сбрасываются в ноль SWS_PlatformHealthManagement с. 31. После активации контроль переходит в состояние kOK, пока выполняются все критерии проверки. При возникновении нарушения статус переходит в kFailed [SWS_PHM_01358].

Диаграмма состояний: переходы состояний элементарного контроля (ElementarySupervisionStatus) от kDEACTIVATED через kOK до kFailed. Источники: [SWS_PHM_01358], SWS_PlatformHealthManagement с. 31.

Несколько элементарных видов контроля объединяются в вышестоящий глобальный контроль SWS_PlatformHealthManagement с. 24. Согласно спецификации, для каждого сконфигурированного Global Supervision существует ровно один GlobalSupervisionStatus, который жестко привязан к одной Function Group и не может распространяться на несколько групп функций ([SWS_PHM_01137], SWS_PlatformHealthManagement с. 39). Глобальный статус агрегирует результаты по состояниям kDEACTIVATED, kOK, kFAILED, kEXPIRED и kSTOPPED AUTOSAR_AP_SWS_PlatformHealthManagement с. 39. Состояние kOK предполагает, что по меньшей мере один соответствующий контроль работает без ошибок и ни один не находится в состоянии сбоя [SWS_PHM_01137].

Диаграмма состояний: модель состояний глобального статуса контроля (GlobalSupervisionStatus) с kDEACTIVATED, kOK, kFAILED, kEXPIRED и kSTOPPED. Источники: [SWS_PHM_01137], AUTOSAR_AP_SWS_PlatformHealthManagement с. 39, SWS_PlatformHealthManagement с. 39.

Циклическое обслуживание сторожевого таймера и аппаратная защита

Для защиты работоспособности всего вычислительного узла от зависаний или фатальных сбоев системы PHM подключает низкоуровневую подсистему сторожевого таймера через интерфейс apext::phm::WatchdogInterface [SWS_PHM_01255]. Это нативное расширение платформы (Platform Extension) реализуется не через промежуточное ПО сервисов (Service Middleware), а выполняется как детерминированный вызов нативного драйвера AUTOSAR_AP_EXP_SWArchitecture с. 130.

В рамках конфигурируемого цикла PHM внутренне проверяет все активные метрики контроля и при положительном общем статусе отправляет сигнал активности на сторожевой таймер через AliveNotification() ([SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture с. 233). Если это сообщение не поступает в пределах сконфигурированного временного окна — например, из-за блокировки демона PHM или сбоя критического контроля, — интерфейс сторожевого таймера самостоятельно инициирует аппаратную реакцию безопасности [SWS_PHM_01255].

Диаграмма последовательности: периодический анализ результатов контроля и передача сигнала активности (alive) интерфейсу сторожевого таймера. Источники: [SWS_PHM_01255], AUTOSAR_AP_EXP_SWArchitecture с. 233, AUTOSAR_AP_EXP_SWArchitecture с. 130.

Координация действий по восстановлению с компонентом State Management

Если PHM обнаруживает нарушение условий контроля, он не инициирует устранение ошибок самостоятельно, а делегирует данную меру компоненту State Management как центральной регулирующей инстанции (AUTOSAR_AP_EXP_SWArchitecture с. 129, AUTOSAR_AP_EXP_SWArchitecture с. 220). Такое разделение сохраняет архитектурный принцип, согласно которому решения о функциональных состояниях системы и перезапусках процессов остаются в ведении State Management AUTOSAR_AP_SWS_StateManagement с. 28.

State Management регистрирует свою готовность к обработке ошибок через интерфейс порта ara::phm::RecoveryAction [SWS_PHM_01141]. Вызовом Offer() активируется прием сообщений об ошибках [SWS_PHM_01143]; с помощью StopOffer() State Management может снова отключить готовность к обслуживанию [SWS_PHM_01144]. Во избежание фатальных состояний гонки и неопределенного поведения из-за преждевременного вызова функции обратного вызова до полного конструирования производных классов операции копирования и перемещения для RecoveryAction явно запрещены ([SWS_PHM_01149], [SWS_PHM_01150], [SWS_PHM_01151], [SWS_PHM_01152]).

В случае ошибки PHM вызывает чисто виртуальную функцию обратного вызова RecoveryHandler() компонента State Management, передавая событие ошибки ara::exec::ExecutionErrorEvent, а также вид нарушенного контроля TypeOfSupervision [SWS_PHM_01142]. После этого State Management определяет последующее состояние Function Group и инициирует изменение состояния или перезапуск затронутых процессов через Execution Management (AUTOSAR_AP_EXP_SWArchitecture с. 169, AUTOSAR_AP_EXP_SWArchitecture с. 220).

Диаграмма последовательности: эскалация ошибок в State Management через RecoveryHandler с ветвлением на срабатывание сторожевого таймера в случае сбоя. Источники: [SWS_PHM_01142], [SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture с. 234, AUTOSAR_AP_EXP_SWArchitecture с. 220, AUTOSAR_AP_EXP_SWArchitecture с. 220.

Поведение при сбоях и многоуровневые пути эскалации

Platform Health Management реализует ступенчатую стратегию эскалации для обработки ошибок времени выполнения AUTOSAR_AP_EXP_SWArchitecture с. 200. При возникновении ошибки контроля сначала задействуется первичный путь: контроль сообщает об ошибке в State Management, который выполняет контролируемую реконфигурацию через RecoveryHandler() [SWS_PHM_01142].

Если State Management не может выполнить восстановление (например, возвращая код ошибки PhmErrc::kSMCanNotHandleRecovery) или ответ завершается по таймауту, вступает в действие вторичный путь эскалации ([SWS_PHM_01240], AUTOSAR_AP_EXP_SWArchitecture с. 220). В этом случае PHM обходит программный уровень и принудительно запускает немедленную низкоуровневую аварийную реакцию через FireWatchdogReaction() (сброс системы или переход в безопасное состояние) ([SWS_PHM_01256], AUTOSAR_AP_EXP_SWArchitecture с. 201).

Особенно критичен сбой самих центральных демонов платформы: при отказе Execution Management или State Management скоординированное восстановление на уровне операционной системы становится невозможным (AUTOSAR_AP_EXP_SWArchitecture с. 235, AUTOSAR_AP_EXP_SWArchitecture с. 235). PHM распознает это состояние по ошибочным или отсутствующим контрольным точкам от этих демонов и без задержки инициирует реакцию сторожевого таймера [SWS_PHM_01256].

Все ошибочные ситуации в C++-API типизируются через домен ошибок ara::phm::PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]). Коды ошибок сгруппированы в перечислении PhmErrc ([SWS_PHM_01240], [SWS_PHM_01245]). Для синхронных интерфейсов и исключений доступны вспомогательные функции, такие как MakeErrorCode() [SWS_PHM_01244], а также тип исключения PhmException ([SWS_PHM_01243], [SWS_PHM_01250]).

Моделирование в манифесте, синхронизация ID и инстанцирование

Корректная связь между кодом приложения и демоном PHM основана на строгой синхронизации ID в манифесте AUTOSAR AUTOSAR_AP_TPS_ManifestSpecification с. 566. В дизайне приложения сущность моделируется как PhmSupervisedEntityInterface с агрегированными элементами PhmCheckpoint AUTOSAR_AP_TPS_ManifestSpecification с. 208. Для развертывания на уровне машины для каждого экземпляра процесса создается SupervisionCheckpoint, который разрешает ссылку экземпляра на порт и контекст выполнения (Process) TPS_ManifestSpecification с. 568.

Если один и тот же тип программного компонента инстанцируется несколько раз — внутри одного и того же процесса или в нескольких процессах, — конфигурация манифеста создает уникальный InstanceSpecifier для каждого порта AUTOSAR_AP_SWS_PlatformHealthManagement с. 51. Благодаря этому демон PHM может однозначно сопоставлять идентичные ID контрольных точек из исходного кода с соответствующим экземпляром компонента и идентификатором процесса AUTOSAR_AP_TPS_ManifestSpecification с. 566. Интерпретация: межпроцессное взаимодействие между пользовательским пространством приложения и демоном PHM, вероятно, оптимизировано с учетом специфики операционной системы (например, через разделяемую память или доменные сокеты POSIX), поскольку C++-класс SupervisedEntity прозрачно инкапсулирует детали транспорта [SWS_PHM_01123]. Вопрос (открытый)

Со стороны обработки ошибок манифест моделирует элементы RecoveryNotification, сопоставленные с PPortPrototype компонента State Management AUTOSAR_AP_TPS_ManifestSpecification с. 587. При этом также определяется значение таймаута (recoveryNotificationTimeout), по истечении которого обработка ошибки считается неудавшейся AUTOSAR_AP_TPS_ManifestSpecification с. 587.

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

Обязательное нормативное оформление Platform Health Management в релизе R25-11 опирается, в частности, на следующие опорные пункты спецификации:

• Ключевые элементы контроля: [SWS_PHM_01123] и [SWS_PHM_01127] определяют C++-класс SupervisedEntity и механизм сообщений ReportCheckpoint(); [SWS_PHM_01130], а также [SWS_PHM_01380] регламентируют активацию и деактивацию.
• Модели состояний: [SWS_PHM_01358] определяет элементарные состояния (kDEACTIVATED, kOK, kFailed); [SWS_PHM_01137] закрепляет глобальную агрегацию статусов для каждой функциональной группы SWS_PlatformHealthManagement с. 39.
• Восстановление и эскалация: [SWS_PHM_01141], [SWS_PHM_01142] и [SWS_PHM_01143] управляют предоставлением и выполнением RecoveryHandler() в State Management; [SWS_PHM_01256] обеспечивает аварийную эскалацию через аппаратный сторожевой таймер.
• Домен ошибок и исключения: [SWS_PHM_01240] вводит коды ошибок (PhmErrc), передаваемые через PhmErrorDomain ([SWS_PHM_01247], [SWS_PHM_01251]) и PhmException [SWS_PHM_01243].