classe ara::sm::s2r::S2RHub

No State Management, a classe ara::sm::s2r::S2RHub coordena a entrada e a saída do estado Suspend-to-RAM para aplicações satélite registradas (AUTOSAR_AP_EXP_SWArchitecture §9.2.2.1.4 «Interfaces for Suspend-to-Ram Notifications»). Ela permite que uma aplicação de controle solicite a preparação dos satélites antes de colocar o sistema operacional em estado de suspensão e os retorne à operação normal após o despertar ([SWS_SM_00701], [SWS_SM_81112]). O uso da API C++ exclui estritamente a abordagem interna de StateMachine e exige permissões de IAM verificadas ([SWS_SM_00684], [SWS_SM_00706]).

mais ›

Contexto

A classe ara::sm::s2r::S2RHub constitui a interface central do State Management para a coordenação de transições de Suspend-to-RAM na Adaptive Platform (AUTOSAR_AP_EXP_SWArchitecture §9.2.2.1.4 «Interfaces for Suspend-to-Ram Notifications»). Para otimizar o tempo de desligamento e inicialização da máquina, pode-se utilizar um Suspend-to-RAM em vez de uma reinicialização completa do sistema (AUTOSAR_AP_SWS_StateManagement §7.5 «Interaction with Suspend-to-RAM Functionality»). A tarefa primária do hub consiste em acionar todas as instâncias satélite ativamente registradas (ara::sm::s2r::S2RSatellite) para iniciar uma preparação ordenada antes de colocar o sistema operacional no estado de suspensão e coordenar a retomada da operação após o despertar ([SWS_SM_00701], [SWS_SM_00703]).

O uso da classe S2RHub é reservado a aplicações de controle dedicadas, como a SMControlApplication, e não se destina a Adaptive Applications regulares (AUTOSAR_AP_EXP_SWArchitecture §9.2.2.1.4 «Interfaces for Suspend-to-Ram Notifications»). O acesso à funcionalidade de hub pode ocorrer pela API C++ ou internamente pela abordagem de StateMachine; ambas as variantes são mutuamente exclusivas de forma estrita para evitar condições de corrida e inconsistências de estado (AUTOSAR_AP_SWS_StateManagement §7.5.1 «S2R Hub», AUTOSAR_AP_SWS_StateManagement §7.7.15 «Mutual exclusivity of StateMachine approach and S2RHub API usage», [SWS_SM_00684]). A interação com processos e satélites é protegida por Identity and Access Management (IAM) ([SWS_SM_00706], [SWS_SM_00714], [SWS_SM_00715]).

Diagrama de contexto: incorporação do S2RHub entre a aplicação de controle, satélites e sistema operacional. Fontes: AUTOSAR_AP_EXP_SWArchitecture §9.2.2.1.4, AUTOSAR_AP_SWS_StateManagement §7.5.1, [SWS_SM_81112].

Ciclo de vida

Uma instância de ara::sm::s2r::S2RHub é criada explicitamente por meio de um ara::core::InstanceSpecifier ([SWS_SM_81103]). Durante a construção, ocorre uma verificação mandatória de permissão de IAM, na qual o contexto do processo chamador é validado em relação ao mapeamento do modelo (SuspendToRamHubMapping.process) ([SWS_SM_00706], [SWS_SM_00714]). Operações de cópia estão completamente desabilitadas para a classe ([SWS_SM_81107], [SWS_SM_81109]). No entanto, a classe suporta semântica de movimento via construtor de movimento e operador de atribuição por movimento ([SWS_SM_81106], [SWS_SM_81108]).

Em termos de concorrência, o construtor parametrizado e as operações de movimento são especificados como thread-safe ([SWS_SM_81103], [SWS_SM_81106], [SWS_SM_81108]). Por outro lado, o destrutor virtual ~S2RHub() e os métodos operacionais para coordenação de suspensão não são thread-safe ([SWS_SM_81105], [SWS_SM_81110], [SWS_SM_81111], [SWS_SM_81112]). Os chamadores devem, portanto, assegurar que a destruição e a execução das transições ocorram sequencialmente e sem chamadas concorrentes.

Caminho de utilização

O fluxo regular para o início e o término do Suspend-to-RAM divide-se em três fases sucessivas:

1. Preparação do estado de suspensão: Antes de suspender o sistema operacional, os grupos de funções com processos não suportados devem ser encerrados (AUTOSAR_AP_SWS_StateManagement §7.5). Em seguida, a aplicação de controle chama RequestToEnterSuspendMode() no hub ([SWS_SM_81110]). O hub notifica todos os satélites registrados via Offer por meio de EnterSuspendMode ([SWS_SM_00701], [SWS_SM_00710], [SWS_SM_00711]). O método retorna um ara::core::Future<void>, que só é concluído quando todos os satélites endereçados tiverem respondido, se desregistrado ou entrado em timeout ([SWS_SM_00702], [SWS_SM_81110]).
2. Disparo da suspensão do sistema: Após o retorno bem-sucedido de todos os satélites, o chamador dispara o sistema operacional por meio da função síncrona EnterSuspendToRamOs() para colocar a máquina no modo Suspend-to-RAM ([SWS_SM_81112]).
3. Retomada após o wake-up: Assim que o sistema operacional desperta, a aplicação de controle inicia a retomada da operação regular via RequestToLeaveSuspendMode() ([SWS_SM_81111]). O hub solicita a todos os satélites ativos, por meio de sua função de callback, que saiam do modo de suspensão ([SWS_SM_00703], [SWS_SM_00711]). O future retornado é resolvido positivamente quando todos os satélites confirmam positivamente ou se desregistram via StopOffer ([SWS_SM_00707], [SWS_SM_81111]).

Diagrama de sequência: ordem típica de chamadas para preparação da suspensão, execução da suspensão do OS e subsequente reativação. Fontes: [SWS_SM_00701], [SWS_SM_00702], [SWS_SM_00703], [SWS_SM_00707], [SWS_SM_81110], [SWS_SM_81111], [SWS_SM_81112].

Cenários de erro

Condições de erro em S2RHub são sinalizadas, dependendo da fase, por meio de violações de arquitetura ou por códigos de erro no ara::core::Future:

• Erros de construção e violações: Se a verificação de permissão do processo chamador falhar, a violação InsufficientPermissionsViolation e o evento de segurança SEV_ACCESS_CONTROL_SM_IAM_ACCESS_DENIED são disparados ([SWS_SM_00706], [SWS_SM_81103]). Outras violações definidas incluem InstanceSpecifierMappingIntegrityViolation (invalidade do identificador do modelo), PortInterfaceMappingViolation (tipo de interface incompatível), ProcessMappingViolation (atribuição de processo ausente), InstanceSpecifierAlreadyInUseViolation (uso múltiplo no mesmo processo) e AraNotInitializedViolation (inicialização ausente da Adaptive Platform) ([SWS_SM_81103]).
• Erros ao entrar no estado de suspensão: Se a comunicação em camadas inferiores falhar, o future de RequestToEnterSuspendMode() falha com SmErrc::kCommunicationFailed ([SWS_SM_81110]). Se pelo menos um satélite não responder dentro da janela de tempo configurável (padrão: 1000 ms), isso resulta em SmErrc::kCommunicationTimeout ([SWS_SM_81110]). Ambos os erros possuem semântica de rollback. Se pelo menos um satélite reportar a rejeição da transição, o future retorna o erro SmErrc::kAtLeastOneRejected sem semântica de rollback ([SWS_SM_81110]).
• Erros ao sair do estado de suspensão: De forma análoga, problemas de comunicação ou timeouts em RequestToLeaveSuspendMode() levam a SmErrc::kCommunicationFailed ou SmErrc::kCommunicationTimeout, respectivamente ([SWS_SM_00707], [SWS_SM_81111]). Se um satélite responder com kRejected, o future reporta o código de erro SmErrc::kAtLeastOneHadIssuesToLeave ([SWS_SM_00707], [SWS_SM_81111]).
• Registro de satélite rejeitado: Tentativas de registro de satélites são rejeitadas pelo hub caso o contexto de processo deles não corresponda à configuração do modelo ([SWS_SM_00715]).