модуль ara::sm — State Management

Адаптивный кластер State Management управляет общесистемными рабочими режимами, состояниями функциональных групп и фазами обновления программного обеспечения в Adaptive Machine совместно с Execution Management и UCM EXP SWArchitecture с. 51. Он детерминированно обрабатывает триггеры переходов с помощью сконфигурированных таблиц и списков действий, сообщает о промежуточных состояниях через StateMachineNotification и оркестрирует Suspend-to-RAM по шаблону «концентратор — сателлит» (Hub-Satellite) [SWS_SM_91107], [SWS_SM_81110]. Граничные условия, такие как строгая проверка разрешений на обновление и обязательные пути перехвата ошибок ANY, обеспечивают надежное функционирование платформы [SWS_SM_91108].

больше ›

Функциональный кластер State Management (SM) выступает в AUTOSAR Adaptive Platform центральным платформенным демоном для управления состояниями машины и функциональных групп, а также режимами выполнения EXP SWArchitecture с. 51. Он строго отделяет логику принятия решений, специфичную для транспортного средства, в управляющих приложениях (SMControlApplication) от фактического управления процессами со стороны Execution Management (EM) EXP PlatformDesign с. 40. Наряду с проприетарными реализациями производителей AUTOSAR предоставляет стандартизированный подход StateMachine, в котором переходы обрабатываются с помощью табличных метамоделей и сконфигурированных списков действий SWS StateManagement с. 42.

Переходы между состояниями инициируются через метод RequestTransition сервиса StateMachineService [SWS_SM_91107] и валидируются по TransitionRequestTable SWS StateManagement с. 44. Во время выполнения соответствующего ActionList поле оповещения CurrentState сигнализирует переходное значение "inTransition" приложениям-потребителям до того, как целевое состояние будет опубликовано после полного квитирования [SWS_SM_91109], SWS StateManagement с. 67.

Диаграмма последовательности: процесс штатного перехода состояния через StateMachineService и оповещение через StateMachineNotification. Источники: [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement с. 51

Для проведения обновлений программного обеспечения State Management предоставляет интерфейс UpdateRequest для Update and Configuration Management (UCM) [SWS_SM_91102], EXP SWArchitecture с. 56. После проверки прикладного поля UpdateAllowed модуль координирует шаги подготовки (PrepareUpdate), верификации (VerifyUpdate) или отката (PrepareRollback), а также перезапуски машины через ResetMachine [SWS_SM_91100], [SWS_SM_91103], [SWS_SM_91108]. Для энергосберегающих режимов, таких как Suspend-to-RAM, S2RHub и S2RSatellite синхронизируют заморозку и возобновление работы приложений и операционной системы [SWS_SM_81010], [SWS_SM_81110], [SWS_SM_71001].

В случае сбоя SmErrorDomain [SWS_SM_81247], а также обязательная запись перехвата ANY в ErrorRecoveryTable гарантируют, что непредвиденные ошибки выполнения от Execution Management или Platform Health Management будут детерминированно перехвачены, а выполняемые действия — немедленно переведены в определенные состояния восстановления SWS StateManagement с. 42.

больше ›

Роль и функциональные границы системы в комплексе платформы

Функциональный кластер State Management (SM) образует в AUTOSAR Adaptive Platform центральный экземпляр для оркестрации общесистемных рабочих режимов, функциональных групп и жизненных циклов процессов EXP SWArchitecture с. 51. Выполняясь как автономный платформенный демон, State Management отделяет внутреннее платформенное исполнение состояний от логики управления, специфичной для транспортного средства и производителя, которая обычно инкапсулирована в отдельном управляющем приложении (SMControlApplication) EXP PlatformDesign с. 40. В то время как State Management принимает и валидирует логические решения о состояниях, физический запуск, завершение и переключение процессов он делегирует через StateClient кластеру Execution Management (EM) SWS StateManagement с. 40.

Архитектурно модуль опирается на дуальную философию интеграции: интеграторы могут либо использовать стандартизированный подход StateMachine на основе манифестов из состава платформенного стека, либо реализовать полностью собственную логику состояний производителя, поскольку интерфейсы к State Management остаются открытыми SWS StateManagement с. 42. В стандартизированном подходе State Management детерминированно реагирует на внешние триггеры от управляющих приложений, сообщения об ошибках от Platform Health Management (PHM), а также смену сетевых состояний от Network Management (NM) SWS StateManagement с. 45. Кроме того, State Management является ключевым контролирующим звеном для обновлений программного обеспечения, выполняемых Update and Configuration Management (UCM) EXP SWArchitecture с. 56.

Контекстная диаграмма: встраивание Functional Cluster State Management в системный комплекс AUTOSAR Adaptive. Источники: EXP PlatformDesign с. 40, SWS StateManagement с. 28

Переходы состояний и управление через интерфейс StateMachineService

Для инициирования изменений состояний State Management предоставляет сервис StateMachineService для каждого сконфигурированного экземпляра StateMachine SWS StateManagement с. 44. Приложение запрашивает переход через сервисный метод RequestTransition [SWS_SM_91107]. State Management проверяет этот запрос с помощью TransitionRequestTable, статически зафиксированной в манифесте, относительно текущего состояния автомата состояний SWS StateManagement с. 44. Если переход определен, выполнение текущего списка действий (ActionList) останавливается и запускается переход в целевое состояние SWS StateManagement с. 45.

Как только запускается переход состояния, State Management устанавливает значение сервисного поля CurrentState интерфейса StateMachineNotification в "inTransition" [SWS_SM_91109], SWS StateManagement с. 67. Это переходное состояние сигнализирует зависимым Adaptive Applications через ara::com о том, что выполняется реконфигурация системы EXP SWArchitecture с. 52. Внутри списков действий функциональные группы могут синхронизироваться или подключаться параллельно с помощью элементов SYNC для точного отображения зависимостей SWS StateManagement с. 56. Только после того, как все ActionListItems будут полностью обработаны, а результаты собраны, CurrentState принимает финальное имя нового состояния SWS StateManagement с. 67.

Диаграмма последовательности: процесс штатного перехода состояния через StateMachineService и оповещение через StateMachineNotification. Источники: [SWS_SM_91107], [SWS_SM_91109], SWS StateManagement с. 51, EXP SWArchitecture с. 219

Диаграмма состояний: типичный жизненный цикл и логика переходов StateMachine на основе TransitionRequestTable. Источники: EXP InterfacesGuidelines с. 22, SWS StateManagement с. 44

Оркестрация обновлений программного обеспечения во взаимодействии с UCM

В рамках обновлений программного обеспечения State Management берет на себя функцию интерфейса между Update and Configuration Management (UCM) и состояниями выполнения машины EXP SWArchitecture с. 142. Для этого State Management предоставляет интерфейс UpdateRequest, который разрешено инстанциировать не более одного раза на машину и который эксклюзивно привязан к процессу, управляющему автоматом состояний контроллера SWS StateManagement с. 79. Обновление инициируется вызовом метода RequestUpdateSession со стороны UCM [SWS_SM_91102]. State Management принимает решение о допустимости не автономно, а опрашивает сервисное поле UpdateAllowed интерфейса UpdateAllowedService, устанавливаемое прикладной логикой управления [SWS_SM_91108], SWS StateManagement с. 81.

Если сессия подтверждается, контроллер помечает затронутые автоматы состояний как ImpactedByUpdate SWS StateManagement с. 81. До фактической установки UCM вызывает PrepareUpdate со списком затронутых функциональных групп, после чего они переводятся в неактивные состояния [SWS_SM_91103], PlatformDesign с. 58. Если обновление требует перезагрузки, UCM через метод типа Fire-and-Forget ResetMachine запрашивает упорядоченный сброс, перед которым все данные должны быть сохранены [SWS_SM_91100]. State Management информирует UCM об изменениях статуса во время сброса через поле ResetMachineNotifier [SWS_SM_91106], SWS StateManagement с. 92. После перезагрузки или обновления следует верификация через VerifyUpdate [SWS_SM_91104], SWS StateManagement с. 87. Если проверка завершается неудачно, PrepareRollback подготавливает откат [SWS_SM_91105], SWS StateManagement с. 88. Завершение всего цикла квитируется с помощью StopUpdateSession [SWS_SM_91101], SWS StateManagement с. 79.

Диаграмма последовательности: процесс взаимодействия во время сессии обновления программного обеспечения между UCM, State Management и логикой управления. Источники: [SWS_SM_91100], [SWS_SM_91102], [SWS_SM_91103], [SWS_SM_91104], SWS StateManagement с. 78

Управление энергопотреблением и Suspend-to-RAM в схеме Hub-Satellite

Для расширенных функций управления энергопотреблением, таких как Suspend-to-RAM (S2R), State Management реализует архитектурный шаблон «концентратор — сателлит» (Hub-Satellite) EXP SWArchitecture с. 54. Центральный управляющий экземпляр в платформенном демоне использует класс S2RHub [SWS_SM_81103], тогда как участвующие Adaptive Applications в своем собственном пространстве процессов подключают экземпляры S2RSatellite [SWS_SM_81003], [SWS_SM_81014], SWS StateManagement с. 35. Сателлиты активируют свою готовность к приему изменений режима через Offer [SWS_SM_81012] или деактивируют ее через StopOffer [SWS_SM_81013]. Они реализуют чисто виртуальные методы EnterSuspendMode [SWS_SM_81010] и LeaveSuspendMode [SWS_SM_81011] в качестве механизма обратного вызова для подготовки к состоянию покоя и последующей обработки.

При инициировании операции Suspend S2RHub асинхронно обращается ко всем зарегистрированным сателлитам через RequestToEnterSuspendMode с настраиваемым таймаутом [SWS_SM_81110]. Если все сателлиты успешно завершили подготовку к состоянию покоя, концентратор (hub) инициирует через EnterSuspendToRamOs перевод операционной системы в состояние сохранения содержимого RAM [SWS_SM_81112], SWS StateManagement с. 101. На аппаратно-зависимом уровне OS-обёртки State Management обращается к apext::sm::PowerStateInterface: она позволяет задавать близкие к аппаратному уровню рабочие состояния через SetPowerState [SWS_SM_71001] на основе перечисления PowerState [SWS_SM_71002], а также выполнять регистрацию и отмену регистрации автономных обработчиков пробуждения через RegisterWakeUpHandler [SWS_SM_71003] и UnregisterWakeUpHandler [SWS_SM_71005] с типом функции WakeUpHandler [SWS_SM_71004], SWS StateManagement с. 105. После пробуждения концентратор запрашивает через RequestToLeaveSuspendMode скоординированный перезапуск всех сателлитов [SWS_SM_81111].

Диаграмма последовательности: двухфазный процесс перевода системы в режим Suspend-to-RAM и последующего пробуждения. Источники: [SWS_SM_71001], [SWS_SM_81110], [SWS_SM_81112], SWS StateManagement с. 101

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

Модуль определяет для собственных эксплуатационных ошибок SmErrorDomain [SWS_SM_81247], которая запрашивается через GetSmDomain [SWS_SM_81251] и имеет идентификатор "Sm" [SWS_SM_81248]. Она предоставляет описания ошибок [SWS_SM_81249] и в исключительных случаях преобразует коды через ThrowAsException в SmException [SWS_SM_81243], [SWS_SM_81250]. С помощью перечисления SmErrc типизируются конкретные причины сбоев, в том числе kOfferFailed для обрывов соединения с демоном платформы и kCommunicationFailed для сбоев связи с сателлитами [SWS_SM_81240], создаваемые посредством MakeErrorCode [SWS_SM_81244].

В области логических конечных автоматов State Management обеспечивает сплошную обработку ошибок с помощью ErrorRecoveryTable SWS StateManagement с. 69. Каждая таблица в обязательном порядке должна содержать ровно одну запись со значением ANY, которая служит детерминированным резервным путем перехвата для всех явно не сопоставленных ошибок выполнения SWS StateManagement с. 42, SWS StateManagement с. 69. Если об ошибке сообщает Platform Health Management или Execution Management и затронутый автомат состояний не помечен как ImpactedByUpdate, он устанавливает внутренний флаг текущего восстановления после ошибки, немедленно прерывает текущий список действий и сразу переключается в параметризованное состояние восстановления SWS StateManagement с. 42. При критических ошибках Execution Management, таких как kIntegrityOrAuthenticityCheckFailed, State Management исходит из того, что надежность платформы скомпрометирована и последующие запросы завершатся сбоем, вследствие чего корректирующие меры лежат за пределами кластера SWS StateManagement с. 40.

Диаграмма деятельности: процесс принятия решений и обработки при входящих ошибках выполнения и анализ ErrorRecoveryTable. Источники: SWS StateManagement с. 42, SWS StateManagement с. 69

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

Архитектура и пути взаимодействия State Management подтверждаются следующими нормативными требованиями и проектными решениями:

• Управление системой и переходы: [SWS_SM_91107] определяет сервис-ориентированное требование к переходу, тогда как [SWS_SM_91109] регламентирует поле уведомлений для развязки приложений. Табличное управление подкрепляется SWS StateManagement с. 44.
• Интеграция с обновлением ПО: методы управления сессией [SWS_SM_91102], подготовки [SWS_SM_91103], верификации [SWS_SM_91104], подготовки к откату [SWS_SM_91105] и завершения [SWS_SM_91101], а также сбросы машины [SWS_SM_91100] и поля разрешения [SWS_SM_91106], [SWS_SM_91108] фиксируют взаимодействие с UCM согласно EXP SWArchitecture с. 56.
• Suspend-to-RAM и управление питанием: нативная иерархия классов и интерфейсов вокруг S2RHub [SWS_SM_81103], [SWS_SM_81110], S2RSatellite [SWS_SM_81003], [SWS_SM_81010] и интерфейс операционной системы [SWS_SM_71001], [SWS_SM_71003] образуют нормативный фундамент энергосбережения EXP SWArchitecture с. 54.
• Пространство ошибок: построение стандартизированного домена ошибок с генераторами исключений и ErrorCode опирается на [SWS_SM_81240], [SWS_SM_81244] и [SWS_SM_81247].