модуль ara::exec — Execution Management

Модуль Execution Management в качестве центрального системного демона платформы управляет детерминированным жизненным циклом POSIX-процессов на AUTOSAR Adaptive Platform (AUTOSAR AP SWS ExecutionManagement с. 18). Он принимает состояния выполнения через ExecutionClient ([SWS_EM_02003]) и асинхронно реализует переходы групп функций, запрошенные State Management, запуская и завершая процессы ([SWS_EM_02278]). Существенными граничными условиями являются запрет зависимостей запуска между различными группами функций, а также строгая эскалация ошибок при нарушении временных рамок (SWS ExecutionManagement с. 65).

больше ›

Функциональный кластер Execution Management (EM) представляет собой центральный системный демон платформы AUTOSAR Adaptive Platform для детерминированного управления процессами и контроля их жизненного цикла в пользовательском пространстве POSIX (AUTOSAR AP SWS ExecutionManagement с. 18). Он строго разделяет принятие решений на основе политик (Policy) и техническую реализацию (Mechanism): в то время как State Management задаёт целевые состояния, EM контролирует создание процессов, очередность и обработку сигналов (AUTOSAR AP EXP SWArchitecture с. 56). Через [SWS_EM_02562] ExecutionClient приложения и сервисы платформы сообщают о своём состоянии [SWS_EM_02000] kRunning с помощью [SWS_EM_02003] ReportExecutionState(), тогда как State Management запрашивает смену состояний через [SWS_EM_02276] StateClient (AUTOSAR AP EXP SWArchitecture с. 48).

Контекстная диаграмма: интеграция Execution Management как центрального демона между State Management, операционной системой POSIX и клиентскими процессами. Источники: AUTOSAR AP EXP SWArchitecture с. 56, AUTOSAR AP SWS ExecutionManagement с. 18, [SWS_EM_02003], [SWS_EM_02278].

После запуска операционной системой EM инициализирует State Management и синхронизирует его через [SWS_EM_02279] GetInitialMachineStateTransitionResult() с состоянием машины Startup (AUTOSAR AP SWS ExecutionManagement с. 52). Последующие переходы состояний [SWS_EM_02586] FunctionGroup инициируются асинхронно с помощью [SWS_EM_02278] SetState(): EM корректно завершает больше не требующиеся процессы через SIGTERM, запускает последующие процессы с учётом локальных зависимостей запуска и выполняет результирующий Future, как только все процессы будут готовы к работе (AUTOSAR AP SWS ExecutionManagement с. 53, SWS ExecutionManagement с. 71).

Диаграмма последовательности: успешная смена состояния группы функций с корректным завершением процессов и перезапуском процессов. Источники: AUTOSAR AP SWS ExecutionManagement с. 53, AUTOSAR AP SWS StateManagement с. 26, [SWS_EM_02278], [SWS_EM_02003].

Для обеспечения требований реального времени EM поддерживает детерминированное предварительное отображение процессов (Pre-Mapping) во избежание ошибок отсутствия страниц (Page-Faults) (SWS ExecutionManagement с. 82), а также детерминированные пулы рабочих потоков (Worker-Pools) и механизмы синхронизации (SWS ExecutionManagement с. 86, SWS ExecutionManagement с. 92). Если процесс нарушает своё временное окно запуска, задействуется обработка ошибок: EM завершает процесс, переводит группу функций в состояние Undefined State, вызывает зарегистрированный callback ([SWS_EM_02276]) и предоставляет сведения об ошибке через [SWS_EM_02542] GetExecutionError() и домен ошибок модуля [SWS_EM_02281] ExecErrc (AUTOSAR AP SWS ExecutionManagement с. 54).

больше ›

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

Модуль exec (Execution Management, EM) представляет собой центральный сервис платформы AUTOSAR Adaptive Platform для детерминированного управления процессами и жизненным циклом в пользовательском пространстве на базе POSIX (AUTOSAR AP SWS ExecutionManagement с. 18). Характерной архитектурной чертой является строгое разделение решения по управлению (Policy) и технического исполнения (Mechanism): в то время как функциональный кластер State Management принимает высокоуровневые решения о режимах работы и переходах, Execution Management выступает в качестве исполнительного органа для выделения ресурсов процессам, порядка запуска, мониторинга и завершения (AUTOSAR AP EXP SWArchitecture с. 56).

Execution Management реализует нативные интерфейсы времени выполнения C++ для двух взаимодополняющих ролей: через класс [SWS_EM_02562] ara::exec::ExecutionClient процессы приложений, а также внутренние демоны платформы (такие как Diagnostic Management, Platform Health Management или Communication Management) сообщают о своём состоянии выполнения демону (AUTOSAR AP EXP SWArchitecture с. 48, AUTOSAR AP SWS CommunicationManagement с. 34). Через интерфейс [SWS_EM_02276] ara::exec::StateClient State Management взаимодействует с демоном для запроса переходов групп функций и переходов машины, а также для опроса сообщений о состоянии (AUTOSAR AP SWS ExecutionManagement с. 17).

Контекстная диаграмма: интеграция Execution Management как центрального демона между State Management, операционной системой POSIX и клиентскими процессами. Источники: AUTOSAR AP EXP SWArchitecture с. 56, AUTOSAR AP SWS ExecutionManagement с. 18, [SWS_EM_02003], [SWS_EM_02278].

Архитектура состояний и многоуровневая модель жизненного цикла

Управление состояниями в Execution Management функционирует на трёх взаимосвязанных иерархических уровнях: высокоуровневых состояниях групп функций (Function Group States), внешних состояниях жизненного цикла операционной системы с точки зрения демона (Process States) и внутренних состояниях процессов (Execution States) (AUTOSAR EXP PlatformDesign с. 29, AUTOSAR AP SWS ExecutionManagement с. 62). На уровне демона сконфигурированный процесс обычно проходит цепочку Idle, Starting, Running, Terminating и Terminated (AUTOSAR AP SWS StateManagement с. 32).

Для внутреннего представления процесса модуль определяет перечисление [SWS_EM_02000] ara::exec::ExecutionState. При этом нормативно передаваемым в Execution Management является состояние kRunning через функцию-член [SWS_EM_02003] ReportExecutionState(). Предшествующие фазы, такие как Initializing, являются неявными состояниями для Execution Management, которые начинаются непосредственно с первым планированием POSIX-процесса до выполнения пользовательского кода ([SWS_EM_02000], AUTOSAR EXP AdaptivePlatformInterfacesGuidelines с. 11). Прикладные режимы работы и энергопотребления (PowerModes) не представляют собой состояния операционной системы, а логически привязаны к активной фазе жизненного цикла Running (AUTOSAR AP SWS StateManagement с. 32).

Диаграмма состояний: корреляция состояний групп функций с фазами жизненного цикла в Execution Management и внутренними состояниями процессов. Источники: AUTOSAR EXP PlatformDesign с. 29, AUTOSAR AP SWS ExecutionManagement с. 32, [SWS_EM_02000].

Детерминированный запуск платформы и инициализация

Запуск AUTOSAR Adaptive Platform происходит в строго скоординированной последовательности, начиная с ядра операционной системы (AUTOSAR EXP SWArchitecture с. 148). Операционная система запускает Execution Management через его точку входа в программу main() (AUTOSAR AP SWS ExecutionManagement с. 52). Непосредственно после собственной инициализации Execution Management создаёт процесс State Management (AUTOSAR AP SWS StateManagement с. 25).

Как только State Management инициализируется, он сообщает о своей готовности к работе с [SWS_EM_02003] ReportExecutionState(ExecutionState::kRunning) через ExecutionClient в Execution Management (AUTOSAR AP SWS ExecutionManagement с. 52). Вслед за этим State Management синхронизируется через [SWS_EM_02279] GetInitialMachineStateTransitionResult() с завершением начального перехода машины в состояние Startup; этот метод возвращает ara::core::Future<void> ([SWS_EM_02279], AUTOSAR EXP SWArchitecture с. 151). Только после успешного выполнения этого future State Management запрашивает переход в последующие состояния групп функций (AUTOSAR AP SWS StateManagement с. 24).

Диаграмма последовательности: запуск платформы от инициации операционной системой через запуск State Management до разблокировки последующего состояния. Источники: AUTOSAR AP SWS ExecutionManagement с. 52, AUTOSAR AP SWS StateManagement с. 25, [SWS_EM_02279], [SWS_EM_02003].

Управление группами функций и асинхронные переходы состояний

Смены состояний моделируются на прикладном уровне через представителей классов [SWS_EM_02586] ara::exec::FunctionGroup и [SWS_EM_02324] ara::exec::FunctionGroupState. Для обеспечения детерминированного управления ресурсами FunctionGroup не поддерживает копирование ([SWS_EM_02322], [SWS_EM_02327]), а допускает исключительно перемещение ([SWS_EM_02328], [SWS_EM_02329]) и вычисление через сравнение экземпляров ([SWS_EM_02267], [SWS_EM_02268]). FunctionGroupState связывает группу функций с целевым состоянием ([SWS_EM_02324]) и поддерживает как семантику копирования, так и перемещения ([SWS_EM_02325], [SWS_EM_02330], [SWS_EM_02331], [SWS_EM_02332], [SWS_EM_02273], [SWS_EM_02274]).

State Management инициирует переход вызовом [SWS_EM_02278] StateClient::SetState(), что синхронно возвращает ara::core::Future<void> (AUTOSAR AP SWS StateManagement с. 31). После этого Execution Management выполняет цепочку переходов: работающие процессы, которые больше не сконфигурированы в целевом состоянии, получают сигнал SIGTERM (AUTOSAR AP SWS ExecutionManagement с. 53). После их завершения EM запускает процессы, предусмотренные для целевого состояния, и ожидает их сообщения о состоянии через [SWS_EM_02003] ReportExecutionState() (AUTOSAR AP SWS StateManagement с. 26, AUTOSAR SWS ExecutionManagement с. 49). Только когда все задействованные процессы успешно запущены, future из SetState() разрешается положительно (AUTOSAR AP SWS ExecutionManagement с. 53).

Зависимости запуска (Execution Dependencies) никогда не должны определяться за пределами отдельной группы функций или между различными состояниями (SWS ExecutionManagement с. 65). При смене состояний Execution Management разрешает зависимости запуска строго для процессов запрошенного целевого состояния (RequestedState) (SWS ExecutionManagement с. 71). Если конфигурации запуска процесса между исходным и целевым состояниями различаются, Execution Management принудительно выполняет его перезапуск (SWS ExecutionManagement с. 65).

Диаграмма последовательности: успешная смена состояния группы функций с корректным завершением процессов и перезапуском процессов. Источники: AUTOSAR AP SWS ExecutionManagement с. 53, AUTOSAR AP SWS StateManagement с. 26, [SWS_EM_02278], [SWS_EM_02003].

Конфигурация процессов, выделение памяти и предварительное отображение

В реальных системах помимо стандартных приложений существуют также процессы без встроенного информирования о состоянии (Non-reporting Processes). Такие процессы после запуска автоматически переходят в состояние выполнения Running (SWS ExecutionManagement с. 44). Чтобы тем не менее обезопасить цепочки зависимостей, можно предварительно подключить специализированный сопутствующий процесс проекта (Companion Process), который оценивает функциональную готовность non-reporting-процесса к работе и от его имени сообщает [SWS_EM_02003] kRunning до запуска зависимых последующих процессов (SWS ExecutionManagement с. 44, SWS ExecutionManagement с. 48).

Что касается потребности в ресурсах, параметр resourceConsumption.memoryUsage ограничивает оперативную память, выделяемую самим процессом, что в POSIX-системах обычно реализуется через RLIMIT_AS (SWS ExecutionManagement с. 82, SWS ExecutionManagement с. 104). Для обеспечения временного детерминизма и функциональной безопасности Execution Management поддерживает предварительное отображение (Pre-mapping): если Process.preMapping активирован в манифесте, EM предварительно полностью отображает код и области данных процесса в физическую память (SWS ExecutionManagement с. 82). Это предотвращает задержки из-за подгрузки по требованию (Demand-Loading) при первом доступе, гарантирует постоянную доступность критически важных для безопасности процедур обработки ошибок и защищает от последующих сбоев из-за повреждённых файловых систем (SWS ExecutionManagement с. 82).

Детерминированное время выполнения и модели синхронизации

Для критичных к реальному времени приложений Execution Management предоставляет механизмы детерминированного выполнения (SWS ExecutionManagement с. 79). Циклические процессы взаимодействуют с клиентом через API точек ожидания, который контролирует такие режимы, как обнаружение сервисов (Service-Discovery), инициализация, выполнение и завершение (SWS ExecutionManagement с. 79). Параллельная обработка данных абстрагируется через пулы рабочих потоков (Worker Pools): для обеспечения детерминизма данных обмен данными между параллельными экземплярами WorkerRunnable запрещён (SWS ExecutionManagement с. 86).

Для синхронизации нескольких избыточных или распределённых процессов применяется DeterministicSyncMaster (SWS ExecutionManagement с. 92). При событийно-управляемой активации конфигурируемая политика (например, мажоритарное решение M из N) определяет, когда отправляются ответы синхронизации (SWS ExecutionManagement с. 92). При периодической активации однократная синхронизация выполняется в начале, после чего глобальный буфер временных меток задаёт начальный цикл, а последующие циклы автономно управляются с помощью локальных счётчиков и контроля соблюдения сроков (SWS ExecutionManagement с. 92). Sync-Master может быть развёрнут либо как отдельный процесс, либо интегрирован в виде библиотеки в рамках фреймворка программного локстепа (Software-Lockstep) (SWS ExecutionManagement с. 94, SWS ExecutionManagement с. 95).

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

В случае сбоя архитектура структурируется в соответствии с общей схемой отказоустойчивости на обнаружение ошибок (Error Detection) и последующее восстановление после ошибок (Error Recovery) (SWS ExecutionManagement с. 86, SWS ExecutionManagement с. 107). Если во время смены состояния группы функций происходит таймаут запуска (Start-up-Timeout) — например, из-за того, что запускаемый процесс не отправляет [SWS_EM_02003] ReportExecutionState(kRunning) в течение параметризованного срока, — Execution Management прерывает штатный ход выполнения (AUTOSAR AP SWS ExecutionManagement с. 54).

Внутренняя эскалация в этом случае, предположительно, включает принудительное завершение сбойного процесса через SIGKILL; после исчерпания сконфигурированных попыток перезапуска затронутая группа функций переходит в неопределённое состояние (Undefined Function Group State) (AUTOSAR AP SWS ExecutionManagement с. 54, [SWS_EM_02542]). Вопрос Q-5a8b6ad2e9e22eb4 (открытый) При переходе в неопределённое состояние Execution Management инициирует переданный при инстанцировании StateClient callback undefinedStateCallback ([SWS_EM_02276], [SWS_EM_02561]). State Management после этого может через [SWS_EM_02542] GetExecutionError() запросить соответствующее событие ara::exec::ExecutionErrorEvent, которое предоставляет сбойную группу функций ([SWS_EM_02546]) и код ошибки [SWS_EM_02541] ExecutionError ([SWS_EM_02545]) ([SWS_EM_02542]). Если группа функций снова находится в определённом состоянии, GetExecutionError() завершается сбоем ([SWS_EM_02542]).

Диаграмма последовательности: обработка ошибок при таймауте запуска процесса во время перехода состояния. Источники: AUTOSAR AP SWS ExecutionManagement с. 54, [SWS_EM_02278], [SWS_EM_02276], [SWS_EM_02542].

Для унифицированной обработки ошибок модуль предоставляет домен ошибок [SWS_EM_02286] ara::exec::ExecErrorDomain (доступен через [SWS_EM_02290] GetExecErrorDomain(), идентификационное имя через [SWS_EM_02287] Name(), текстовые сообщения через [SWS_EM_02288] Message()). Специфические ошибки выполнения отображаются с помощью кода перечисления [SWS_EM_02281] ExecErrc (например, kNoCommunication) и конструируются через [SWS_EM_02291] MakeErrorCode(). При активированной обработке исключений ошибки могут генерироваться через [SWS_EM_02289] ThrowAsException() в виде [SWS_EM_02283] ExecException. Кроме того, деструктор [SWS_EM_02002] ~ExecutionClient() обеспечивает возврат ранее перенятых обработчиков для SIGTERM к их исходным значениям, тогда как переданные при создании процесса функции обратного вызова для прерывания срабатывают при получении сигнала завершения ([SWS_EM_02560], [SWS_EM_02562]). Более масштабные действия по восстановлению (Recovery Actions, такие как перезапуск процесса или переход в аварийный режим работы) оркестрируются совместно с Platform Health Management (AUTOSAR SWS ExecutionManagement с. 54).

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

Нижеследующий обзор сопоставляет основные требования спецификации и подтверждающие ссылки с рассматриваемыми тематическими областями:

Тематическая область	Основные свидетельства	Функциональное значение
Сообщение о состоянии процесса	[SWS_EM_02000], [SWS_EM_02003], [SWS_EM_02562]	Определяет ExecutionState, создание ExecutionClient и оповещение о kRunning.
Управление функциональными группами	[SWS_EM_02278], [SWS_EM_02586], [SWS_EM_02324]	Асинхронный переход состояния через SetState(), создание экземпляра FunctionGroup и FunctionGroupState.
Запуск платформы	[SWS_EM_02279], AUTOSAR AP SWS ExecutionManagement S. 52	Синхронизация State Management с начальным состоянием машины Startup.
Обработка ошибок & функции обратного вызова	[SWS_EM_02276], [SWS_EM_02542], [SWS_EM_02281]	Регистрация undefinedStateCallback, опрос ExecutionErrorEvent, домен ошибок ExecErrc.
Детерминизм памяти	SWS ExecutionManagement S. 82	Полное предварительное отображение (Pre-Mapping) процессов во избежание задержек из-за динамической загрузки по требованию (Demand-Loading).