módulo ara::exec — Execution Management

O módulo Execution Management gerencia, como daemon central da plataforma, o ciclo de vida determinístico de processos POSIX na AUTOSAR Adaptive Platform (AUTOSAR AP SWS ExecutionManagement p. 18). Ele recebe estados de execução por meio do ExecutionClient ([SWS_EM_02003]) e implementa transições de Function Group solicitadas pelo State Management de forma assíncrona, iniciando e encerrando processos ([SWS_EM_02278]). Condições de contorno essenciais são a proibição de dependências de inicialização entre grupos de funções, bem como o escalonamento rigoroso de erros em caso de violação de prazos (SWS ExecutionManagement p. 65).

mais ›

O cluster funcional Execution Management (EM) constitui o daemon central da plataforma da AUTOSAR Adaptive Platform para o gerenciamento determinístico de processos e controle de ciclo de vida no espaço de usuário POSIX (AUTOSAR AP SWS ExecutionManagement p. 18). Ele separa estritamente a decisão de diretrizes (Policy) da aplicação técnica (Mechanism): enquanto o State Management define os estados-alvo, o EM controla a criação de processos, sequências e tratamento de sinais (AUTOSAR AP EXP SWArchitecture p. 56). Por meio de [SWS_EM_02562] ExecutionClient, aplicações e serviços de plataforma reportam seu estado [SWS_EM_02000] kRunning via [SWS_EM_02003] ReportExecutionState(), enquanto o State Management solicita transições de estado por meio de [SWS_EM_02276] StateClient (AUTOSAR AP EXP SWArchitecture p. 48).

Diagrama de contexto: incorporação do Execution Management como daemon central entre o State Management, o sistema operacional POSIX e os processos clientes. Fontes: AUTOSAR AP EXP SWArchitecture p. 56, AUTOSAR AP SWS ExecutionManagement p. 18, [SWS_EM_02003], [SWS_EM_02278].

Após ser iniciado pelo sistema operacional, o EM inicia o State Management e sincroniza-o por meio de [SWS_EM_02279] GetInitialMachineStateTransitionResult() para o estado de máquina Startup (AUTOSAR AP SWS ExecutionManagement p. 52). As transições subsequentes de estados de [SWS_EM_02586] FunctionGroup são disparadas de forma assíncrona com [SWS_EM_02278] SetState(): o EM encerra de forma ordenada processos não mais necessários via SIGTERM, inicia processos subsequentes considerando as dependências locais de inicialização e cumpre o Future resultante assim que todos os processos estiverem operacionais (AUTOSAR AP SWS ExecutionManagement p. 53, SWS ExecutionManagement p. 71).

Diagrama de sequência: transição de estado bem-sucedida de um Function Group com encerramento ordenado de processos e reinicialização de processos. Fontes: AUTOSAR AP SWS ExecutionManagement p. 53, AUTOSAR AP SWS StateManagement p. 26, [SWS_EM_02278], [SWS_EM_02003].

Para garantir os requisitos de tempo real, o EM suporta o pré-mapeamento determinístico de processos para evitar page faults (SWS ExecutionManagement p. 82), bem como pools de workers determinísticos e mecanismos de sincronização (SWS ExecutionManagement p. 86, SWS ExecutionManagement p. 92). Se um processo violar sua janela de tempo de inicialização, o tratamento de erros entra em ação: o EM encerra o processo, coloca o Function Group em um Undefined State, chama o callback registrado ([SWS_EM_02276]) e disponibiliza detalhes do erro via [SWS_EM_02542] GetExecutionError() e o domínio de erro do módulo [SWS_EM_02281] ExecErrc (AUTOSAR AP SWS ExecutionManagement p. 54).

mais ›

Limites do sistema e papel funcional do Execution Management

O módulo exec (Execution Management, EM) constitui o serviço central da AUTOSAR Adaptive Platform para o gerenciamento determinístico de processos e do ciclo de vida no espaço de usuário baseado em POSIX (AUTOSAR AP SWS ExecutionManagement p. 18). Um traço marcante da arquitetura é a separação estrita entre a decisão de controle (Policy) e a aplicação técnica (Mechanism): enquanto o cluster funcional State Management define os modos de operação de nível superior e toma as decisões de transição, o Execution Management atua como instância executora para a alocação de processos, ordens de inicialização, monitoramento e encerramento (AUTOSAR AP EXP SWArchitecture p. 56).

O Execution Management implementa interfaces de tempo de execução nativas em C++ para dois papéis complementares: por meio da classe [SWS_EM_02562] ara::exec::ExecutionClient, processos de aplicação bem como daemons internos da plataforma (como Diagnostic Management, Platform Health Management ou Communication Management) reportam seu estado de execução ao daemon (AUTOSAR AP EXP SWArchitecture p. 48, AUTOSAR AP SWS CommunicationManagement p. 34). Por meio da interface [SWS_EM_02276] ara::exec::StateClient, o State Management interage com o daemon para solicitar transições de Function Group e de máquina, além de consultar mensagens de status (AUTOSAR AP SWS ExecutionManagement p. 17).

Diagrama de contexto: incorporação do Execution Management como daemon central entre o State Management, o sistema operacional POSIX e os processos clientes. Fontes: AUTOSAR AP EXP SWArchitecture p. 56, AUTOSAR AP SWS ExecutionManagement p. 18, [SWS_EM_02003], [SWS_EM_02278].

Arquitetura de estados e modelo de ciclo de vida em múltiplos níveis

O gerenciamento de estados no Execution Management opera em três níveis hierárquicos correlacionados entre si: os estados de Function Group de nível superior (Function Group States), os estados externos de ciclo de vida do sistema operacional sob a ótica do daemon (Process States), bem como os estados internos dos processos (Execution States) (AUTOSAR EXP PlatformDesign p. 29, AUTOSAR AP SWS ExecutionManagement p. 62). No nível do daemon, um processo configurado percorre tipicamente a cadeia Idle, Starting, Running, Terminating e Terminated (AUTOSAR AP SWS StateManagement p. 32).

Para a visão interna do processo, o módulo define a enumeração [SWS_EM_02000] ara::exec::ExecutionState. Normativamente reportável ao Execution Management é o estado kRunning por meio da função de elemento [SWS_EM_02003] ReportExecutionState(). Fases anteriores como Initializing são estados implícitos para o Execution Management, que se iniciam imediatamente com o primeiro escalonamento do processo POSIX antes da execução do código de usuário ([SWS_EM_02000], AUTOSAR EXP AdaptivePlatformInterfacesGuidelines p. 11). Modos operacionais e de energia aplicados (PowerModes) não representam estados do sistema operacional, mas estão logicamente vinculados à fase ativa do ciclo de vida Running (AUTOSAR AP SWS StateManagement p. 32).

Diagrama de estados: correlação dos estados de Function Group com as fases do ciclo de vida no Execution Management e os estados internos do processo. Fontes: AUTOSAR EXP PlatformDesign p. 29, AUTOSAR AP SWS ExecutionManagement p. 32, [SWS_EM_02000].

Inicialização determinística da plataforma e startup

A inicialização da AUTOSAR Adaptive Platform ocorre em uma sequência estritamente coordenada a partir do kernel do sistema operacional (AUTOSAR EXP SWArchitecture p. 148). O sistema operacional inicia o Execution Management por meio de seu ponto de entrada de programa main() (AUTOSAR AP SWS ExecutionManagement p. 52). Imediatamente após a autoinicialização, o Execution Management cria o processo do State Management (AUTOSAR AP SWS StateManagement p. 25).

Assim que o State Management é inicializado, ele reporta sua prontidão operacional com [SWS_EM_02003] ReportExecutionState(ExecutionState::kRunning) via ExecutionClient ao Execution Management (AUTOSAR AP SWS ExecutionManagement p. 52). Em seguida, o State Management sincroniza-se por meio de [SWS_EM_02279] GetInitialMachineStateTransitionResult() com a conclusão da transição inicial da máquina para o estado Startup; esse método retorna um ara::core::Future<void> ([SWS_EM_02279], AUTOSAR EXP SWArchitecture p. 151). Somente após o cumprimento bem-sucedido desse future, o State Management solicita a transição para estados subsequentes de Function Group (AUTOSAR AP SWS StateManagement p. 24).

Diagrama de sequência: inicialização da plataforma desde a inicialização do sistema operacional, passando pelo início do State Management, até a liberação do estado subsequente. Fontes: AUTOSAR AP SWS ExecutionManagement p. 52, AUTOSAR AP SWS StateManagement p. 25, [SWS_EM_02279], [SWS_EM_02003].

Controle de grupos de funções e transições assíncronas de estado

As transições de estado são modeladas no nível da aplicação por meio de representantes das classes [SWS_EM_02586] ara::exec::FunctionGroup e [SWS_EM_02324] ara::exec::FunctionGroupState. Para garantir o gerenciamento determinístico de recursos, FunctionGroup não é copiável ([SWS_EM_02322], [SWS_EM_02327]), mas exclusivamente móvel ([SWS_EM_02328], [SWS_EM_02329]) e avaliável por meio de comparações de instâncias ([SWS_EM_02267], [SWS_EM_02268]). FunctionGroupState vincula um Function Group a um estado-alvo ([SWS_EM_02324]) e suporta tanto semântica de cópia quanto de movimentação ([SWS_EM_02325], [SWS_EM_02330], [SWS_EM_02331], [SWS_EM_02332], [SWS_EM_02273], [SWS_EM_02274]).

O State Management inicia uma transição chamando [SWS_EM_02278] StateClient::SetState(), o que retorna de forma síncrona um ara::core::Future<void> (AUTOSAR AP SWS StateManagement p. 31). O Execution Management executa então a cadeia de transição: processos em execução que não estejam mais configurados no estado-alvo recebem um sinal SIGTERM (AUTOSAR AP SWS ExecutionManagement p. 53). Após o encerramento deles, o EM inicia os processos previstos para o estado-alvo e aguarda a mensagem de status dos mesmos via [SWS_EM_02003] ReportExecutionState() (AUTOSAR AP SWS StateManagement p. 26, AUTOSAR SWS ExecutionManagement p. 49). Somente quando todos os processos envolvidos tiverem sido iniciados com sucesso, o future de SetState() é cumprido positivamente (AUTOSAR AP SWS ExecutionManagement p. 53).

As dependências de inicialização (Execution Dependencies) nunca devem ser definidas além dos limites de um único Function Group ou mesmo entre estados diferentes (SWS ExecutionManagement p. 65). Em transições de estado, o Execution Management realiza a resolução das dependências de inicialização estritamente para os processos do estado de destino solicitado (RequestedState) (SWS ExecutionManagement p. 71). Se as configurações de inicialização de um processo divergirem entre o estado de origem e o de destino, o Execution Management força a sua reinicialização (SWS ExecutionManagement p. 65).

Diagrama de sequência: transição de estado bem-sucedida de um Function Group com encerramento ordenado de processos e reinicialização de processos. Fontes: AUTOSAR AP SWS ExecutionManagement p. 53, AUTOSAR AP SWS StateManagement p. 26, [SWS_EM_02278], [SWS_EM_02003].

Configuração de processos, alocação de memória e pré-mapeamento

Em sistemas reais, além das aplicações padrão, existem também processos sem reporte de estado integrado (Non-reporting Processes). Tais processos entram automaticamente no estado de execução Running após o arranque (SWS ExecutionManagement p. 44). Para ainda assim proteger cadeias de dependência, pode ser interposto um processo complementar específico do projeto (Companion Process), o qual avalia a prontidão operacional funcional do processo non-reporting e reporta [SWS_EM_02003] kRunning em seu nome, antes que os processos sucessores dependentes sejam iniciados (SWS ExecutionManagement p. 44, SWS ExecutionManagement p. 48).

No que diz respeito aos requisitos de recursos, o parâmetro resourceConsumption.memoryUsage limita a memória principal alocável pelo próprio processo, o que em sistemas POSIX é tipicamente implementado via RLIMIT_AS (SWS ExecutionManagement p. 82, SWS ExecutionManagement p. 104). Para garantir determinismo temporal e segurança funcional, o Execution Management suporta o pré-mapeamento (Pre-mapping): se Process.preMapping estiver ativado no manifesto, o EM pré-mapeia o código e as áreas de dados do processo inteiramente na memória física (SWS ExecutionManagement p. 82). Isto evita atrasos decorrentes de carregamento sob demanda (demand-loading) no primeiro acesso, assegura a disponibilidade contínua de rotinas de tratamento de erros críticas para a segurança e protege contra falhas posteriores causadas por sistemas de arquivos corrompidos (SWS ExecutionManagement p. 82).

Tempo de execução determinístico e modelos de sincronização

Para aplicações com requisitos críticos de tempo real, o Execution Management disponibiliza mecanismos para execução determinística (SWS ExecutionManagement p. 79). Processos cíclicos interagem com o cliente por meio de uma API de ponto de espera, a qual controla modos como descoberta de serviços, inicialização, execução e terminação (SWS ExecutionManagement p. 79). O processamento paralelo de dados é abstraído via worker pools: para assegurar o determinismo de dados, é proibido o intercâmbio de dados entre instâncias concorrentes de WorkerRunnable (SWS ExecutionManagement p. 86).

Para a sincronização de múltiplos processos redundantes ou distribuídos, utiliza-se o DeterministicSyncMaster (SWS ExecutionManagement p. 92). Na ativação baseada em eventos, uma política configurável (como uma decisão por maioria M-de-N) decide quando as respostas de sincronização são enviadas (SWS ExecutionManagement p. 92). Na ativação periódica, ocorre uma sincronização única no início, após a qual um buffer global de carimbos de data/hora define o ciclo inicial e os ciclos subsequentes são controlados autonomamente por meio de contadores locais e monitoramento de prazos (SWS ExecutionManagement p. 92). O sync master pode ser disponibilizado como um processo independente ou integrado como biblioteca no âmbito de um framework de software lockstep (SWS ExecutionManagement p. 94, SWS ExecutionManagement p. 95).

Comportamento em caso de erro

Em caso de falha, a arquitetura divide-se, de acordo com o esquema geral de tolerância a falhas, em deteção de falhas (Error Detection) e subsequente recuperação de falhas (Error Recovery) (SWS ExecutionManagement p. 86, SWS ExecutionManagement p. 107). Se ocorrer um timeout de inicialização durante uma mudança de estado de Function Group – por exemplo, porque um processo que está a iniciar não emite nenhum [SWS_EM_02003] ReportExecutionState(kRunning) dentro do prazo parametrizado –, o Execution Management interrompe o fluxo regular (AUTOSAR AP SWS ExecutionManagement p. 54).

Nesse caso, a escalada interna deverá abranger a terminação forçada do processo defeituoso via SIGKILL; após o esgotamento das tentativas configuradas de reinicialização, o Function Group afetado transita para um estado indefinido (Undefined Function Group State) (AUTOSAR AP SWS ExecutionManagement p. 54, [SWS_EM_02542]). Pergunta Q-5a8b6ad2e9e22eb4 (aberta) Ao entrar num estado indefinido, o Execution Management aciona o callback undefinedStateCallback fornecido durante a instanciação de StateClient ([SWS_EM_02276], [SWS_EM_02561]). O State Management pode então consultar o evento associado ara::exec::ExecutionErrorEvent via [SWS_EM_02542] GetExecutionError(), o qual disponibiliza o Function Group com falha ([SWS_EM_02546]) e o código de erro [SWS_EM_02541] ExecutionError ([SWS_EM_02545]) ([SWS_EM_02542]). Se o Function Group estiver novamente num estado definido, GetExecutionError() falha ([SWS_EM_02542]).

Diagrama de sequência: tratamento de erros em caso de timeout de inicialização de um processo durante uma transição de estado. Fontes: AUTOSAR AP SWS ExecutionManagement p. 54, [SWS_EM_02278], [SWS_EM_02276], [SWS_EM_02542].

Para um tratamento de erros uniforme, o módulo dispõe do domínio de erro [SWS_EM_02286] ara::exec::ExecErrorDomain (acessível via [SWS_EM_02290] GetExecErrorDomain(), nome de identificação via [SWS_EM_02287] Name(), mensagens de texto via [SWS_EM_02288] Message()). Erros de execução específicos são mapeados pelo código de enumeração [SWS_EM_02281] ExecErrc (como kNoCommunication) e construídos via [SWS_EM_02291] MakeErrorCode(). Com o tratamento de exceções ativado, erros podem ser lançados via [SWS_EM_02289] ThrowAsException() como [SWS_EM_02283] ExecException. Além disso, o destrutor [SWS_EM_02002] ~ExecutionClient() assegura que handlers de SIGTERM assumidos anteriormente sejam repostos para o seu valor original, enquanto callbacks de aborto passados durante a criação do processo atuam na receção de um sinal de terminação ([SWS_EM_02560], [SWS_EM_02562]). Ações de recuperação adicionais (recovery actions como reinicialização de processos ou transição para operação de emergência) são orquestradas em cooperação com o Platform Health Management (AUTOSAR SWS ExecutionManagement p. 54).

Evidências mais detalhadas

A visão geral seguinte mapeia os requisitos determinantes da especificação e referências com as áreas temáticas abordadas:

Área temática	Referências essenciais	Significado funcional
Notificação de estado do processo	[SWS_EM_02000], [SWS_EM_02003], [SWS_EM_02562]	Define ExecutionState, criação de ExecutionClient e notificação de kRunning.
Controlo de Function Group	[SWS_EM_02278], [SWS_EM_02586], [SWS_EM_02324]	Transição assíncrona de estado via SetState(), instanciação de FunctionGroup e FunctionGroupState.
Inicialização da plataforma	[SWS_EM_02279], AUTOSAR AP SWS ExecutionManagement S. 52	Sincronização do State Management para o estado inicial da máquina Startup.
Tratamento de erros & callbacks	[SWS_EM_02276], [SWS_EM_02542], [SWS_EM_02281]	Registo do undefinedStateCallback, consulta de ExecutionErrorEvent, domínio de erro ExecErrc.
Determinismo de memória	SWS ExecutionManagement S. 82	Pré-mapeamento completo de processos para evitar latências causadas por demand-loading.