namespace apext::sm

O namespace apext::sm disponibiliza interfaces normativas de extensão de plataforma para coordenar estados de energia entre o AUTOSAR Adaptive State Management e o sistema operativo anfitrião SWS StateManagement §C.1 «Header: apext/sm/power_state_interface.h». Através da enumeração apext::sm::PowerState, são mapeados de forma tipificada modos de poupança de energia específicos do Linux [SWS_SM_71002]. Além disso, o callback apext::sm::WakeUpHandler permite ao sistema operativo desencadear uma saída autónoma dos estados de suspensão no State Management sem uma aplicação de controlo a montante [SWS_SM_71004], sendo que esta chamada não foi concebida para ser thread-safe.

mais ›

Contexto

O namespace apext::sm disponibiliza interfaces normativas de extensão de plataforma (Platform Extension Interfaces) para o Functional Cluster State Management dentro da AUTOSAR Adaptive Platform SWS StateManagement §C.1 «Header: apext/sm/power_state_interface.h». Enquanto as interfaces padrão do State Management servem primariamente para coordenar estados de aplicação, grupos de funções e modos de execução além das fronteiras do modelo, apext::sm aborda o acoplamento de baixo nível. As interfaces de extensão são concebidas para serem utilizadas ou disponibilizadas por OEMs ou integradores para alargar a funcionalidade da plataforma e concretizar uma interação coordenada com o sistema operativo (OS) subjacente SWS StateManagement §C.1 «Header: apext/sm/power_state_interface.h».

O componente central do namespace é a classe PowerStateInterface, que serve para coordenar estados de energia com o sistema operativo. Acompanhando-a, o header apext/sm/power_state_interface.h define enumerações tipificadas e aliases de callback que atuam como elo de ligação entre controladores do sistema operativo, fontes de despertar externas e a gestão de estados interna. Além do sistema operativo, estas interfaces estão concetualmente relacionadas com o Controller do State Management, bem como com instâncias de nível superior, como a SMControlApplication ou o Update and Configuration Management (UCM), que também podem influenciar as transições de estado SWS StateManagement §7.7.15.1 «Autonomous wake-up from suspend state».

Diagrama de contexto: interação entre sistema operativo, interfaces apext::sm e State Management. Fontes: SWS StateManagement §7.7.15.1 «Autonomous wake-up from suspend state», SWS StateManagement §C.1 «Header: apext/sm/power_state_interface.h».

Ciclo de vida

O ciclo de vida no âmbito de apext::sm é marcado pelos estados de energia discretos modelados na enumeração apext::sm::PowerState com base em std::uint32_t [SWS_SM_71002]. Estes estados derivam diretamente da perspetiva do kernel de sistemas operativos Linux:

• kPmSuspendToIdle (= 1): derivado do estado PM_SUSPEND_TO_IDLE [SWS_SM_71002].
• kPmSuspendToRam (= 2): derivado do estado PM_SUSPEND_TO_RAM [SWS_SM_71002].
• kPmHibernation (= 3): derivado do estado PM_HIBERNATION (suspend-to-disk) [SWS_SM_71002].
• kPmOff (= 4): derivado do estado PM_OFF (desligamento completo) [SWS_SM_71002].

Interpretação: a classe PowerStateInterface deverá servir como ponto de ancoragem primário através do qual o integrador consulta ou transmite estes estados-alvo ao sistema operativo anfitrião. Durante a permanência num estado de poupança de energia como kPmSuspendToRam, o processamento normal fica inativo até que um evento de despertar inicie a transição de regresso ao modo de operação ativo. Pergunta Q-800acae699828764 (aberta)

Caminho de utilização

Um caso de uso central do namespace é o despertar autónomo de todo o sistema a partir de um estado de suspensão (Autonomous wake-up from suspend state) SWS StateManagement §7.7.15.1 «Autonomous wake-up from suspend state». Enquanto uma SMControlApplication pode solicitar explicitamente a saída do modo suspend-to-RAM, o State Management é adicionalmente capaz de reagir de forma autónoma a sinais de despertar.

Se o sistema operativo sinalizar um evento de despertar através da interface apext::sm::WakeUpHandler – desde que esta esteja implementada –, o State Management inicia autonomamente uma sequência de despertar SWS StateManagement §7.7.15.1 «Autonomous wake-up from suspend state». apext::sm::WakeUpHandler trata-se de um alias de função do tipo std::function<void(void)> [SWS_SM_71004]. Ao chamar este handler, o State Management transfere a máquina de estados Controller do seu estado de suspensão para o estado LeaveSuspend especialmente modelado para o efeito [SWS_SM_CONSTR_00036]. Neste estado, o controlador executa obrigatoriamente o elemento de ação LeaveSuspendToRam, pelo que a atividade regular da plataforma é retomada sem intervenção prévia de uma aplicação de controlo [SWS_SM_CONSTR_00037], SWS StateManagement §7.7.15.1 «Autonomous wake-up from suspend state».

Diagrama de sequência: fluxo do despertar autónomo através do WakeUpHandler. Fontes: SWS StateManagement §7.7.15.1 «Autonomous wake-up from suspend state», [SWS_SM_71004], [SWS_SM_CONSTR_00036], [SWS_SM_CONSTR_00037].

Cenários de erro

Na utilização e integração de apext::sm devem ser tidas em consideração condições de contorno específicas do sistema e riscos de concorrência:

• Falta de thread-safety: o tipo de chamada apext::sm::WakeUpHandler não é, segundo a especificação, expressamente thread-safe (not thread-safe) [SWS_SM_71004]. Se o sistema operativo ou um contexto de interrupção disparar sinais múltiplos ou paralelos, o integrador deve providenciar mecanismos de sincronização adequados para evitar condições de corrida e transições de estado inconsistentes no State Management.
• Handler não implementado: se o WakeUpHandler não estiver implementado no sistema de destino, não pode ocorrer qualquer despertar autónomo através do sistema operativo; neste caso, o sistema permanece no estado de suspensão até que cheguem pedidos externos (por exemplo, pelo UCM via RequestUpdateSession) ou pedidos explícitos de aplicação SWS StateManagement §7.7.15.1 «Autonomous wake-up from suspend state».
• Erros de modelação no manifesto: se faltar no manifesto de implementação o estado LeaveSuspend para o Controller [SWS_SM_CONSTR_00036] ou se este não contiver o elemento obrigatório LeaveSuspendToRam [SWS_SM_CONSTR_00037], a transição automatizada falha e a plataforma não consegue retomar a operação em conformidade após o estado de suspensão.