ECU State Manager (EcuM)

A função síncrona e reentrante EcuM_GoDownHaltPoll instrui o módulo ECU State Manager a transitar para um modo sleep, um reset ou o estado OFF, dependendo do destino de shutdown selecionado previamente [SWS_EcuM_91002]. Ela está disponível por meio do arquivo de cabeçalho EcuM.h e possui o service ID 0x2c [SWS_EcuM_91002].

Parâmetros e autorização de chamada

Como único parâmetro de entrada, é passado UserID do tipo EcuM_UserType. Este identifica o usuário chamador. Uma chamada é estritamente regulamentada: exclusivamente usuários pré-configurados podem executar esta função [SWS_EcuM_91002].

Valores de retorno e comportamento de execução

O comportamento de retorno depende substancialmente do tipo de destino de shutdown definido [SWS_EcuM_91002]:

• E_NOT_OK: A solicitação não foi aceite [SWS_EcuM_91002].
• E_OK: se o destino for SLEEP, a função retorna com sucesso com este status após sair do estado de suspensão [SWS_EcuM_91002].
• Sem retorno: se tiver sido escolhido como destino de shutdown RESET ou OFF, a chamada da função não retorna mais ao chamador [SWS_EcuM_91002].

Restrições e tratamento de erros

Embora a função seja formalmente declarada como reentrante, sua execução conforme pretendida pressupõe a definição prévia de um destino de shutdown válido [SWS_EcuM_91002]. Códigos de erro específicos de DET ou DEM não estão listados na especificação da interface; uma falha ou a rejeição da solicitação é indicada imediatamente por meio do valor de retorno E_NOT_OK [SWS_EcuM_91002].

A função de serviço síncrona EcuM_Init inicializa o ECU State Manager e inicia a sequência ordenada de inicialização da ECU ([SWS_EcuM_02811]). Ela é declarada por meio do cabeçalho EcuM.h com o Service-ID 0x01, não recebe parâmetros e não retorna nenhum valor de retorno ([SWS_EcuM_02811]). Formalmente classificada como reentrante, EcuM_Init nunca retorna ao chamador após a chamada, pois passa a execução para o sistema operacional ao chamar StartOS ([SWS_EcuM_02811]).

No âmbito de sua execução, a função processa a sequência StartPreOS definida e suas atividades na ordem exatamente especificada ([SWS_EcuM_02411], [SWS_EcuM_02684]). Uma parte essencial dessa fase é a verificação da consistência da configuração: O módulo verifica dentro de EcuM_Init se o respectivo campo da estrutura é idêntico ao valor de ECUM_CONFIGCONSISTENCY_HASH ([SWS_EcuM_02798]).

Além disso, EcuM_Init controla a inicialização dos drivers em sistemas multi-core ([SWS_EcuM_04145]). A função chama em cada Core individual os callouts EcuM_AL_DriverInitZero e EcuM_AL_DriverInitOne ([SWS_EcuM_04145]). Para as implementações dos callouts aplica-se a diretriz de garantir que, no respectivo Core ativo, sejam inicializados exclusivamente os módulos MCAL que são de fato executados nesse Core ([SWS_EcuM_04145]).

A função síncrona e não reentrante EcuM_StartupTwo implementa o estado STARTUP II do ECU State Manager [SWS_EcuM_02838]. A interface é declarada através do arquivo de cabeçalho EcuM.h e possui o Service-ID 0x1a [SWS_EcuM_02838]. De acordo com a assinatura da função void EcuM_StartupTwo(void), a chamada não recebe parâmetros de entrada, de entrada/saída ou de saída e não retorna nenhum valor de retorno ao chamador [SWS_EcuM_02838].

Se o módulo ECU Manager for ativado pela função EcuM_StartupTwo, ele executa as ações da sequência StartPostOS [SWS_EcuM_02932].

Para a integração, existem diretrizes essenciais em relação ao contexto de chamada e à simultaneidade: a função deve obrigatoriamente ser chamada a partir de uma task iniciada diretamente como consequência de StartOS [SWS_EcuM_02806]. Isso requer que a chamada de EcuM_StartupTwo ocorra a partir de uma task de início automático (autostart task) ou de uma task iniciada explicitamente [SWS_EcuM_02806]. Como a função está especificada como não reentrante, nenhuma chamada simultânea ou múltipla pode ocorrer [SWS_EcuM_02838].

A função de serviço síncrona EcuM_Shutdown (Service-ID 0x02) é disponibilizada através do arquivo de cabeçalho EcuM.h e assume o controle de execução para a realização das atividades da fase «GO OFF II» [SWS_EcuM_02812]. Ela serve para a terminação conclusiva do processo de desligamento [SWS_EcuM_02953].

Contexto de chamada e semântica

Tipicamente, a função é chamada a partir do Shutdown-Hook [SWS_EcuM_02812]. De acordo com os requisitos, este hook tem a obrigação explícita de chamar EcuM_Shutdown para finalizar o procedimento de desligamento [SWS_EcuM_02953].

• Assinatura: void EcuM_Shutdown(void) com Service-ID 0x02 [SWS_EcuM_02812].
• Parâmetros: não existem parâmetros de entrada, de saída ou de entrada/saída [SWS_EcuM_02812].
• Valor de retorno: a interface não retorna nenhum valor de retorno [SWS_EcuM_02812].
• Sincronismo: a chamada é executada de forma síncrona [SWS_EcuM_02812].

Simultaneidade e fluxo de controle

Na especificação, EcuM_Shutdown é declarada como reentrante [SWS_EcuM_02812]. Para o fluxo do programa, no entanto, aplica-se o requisito estrito de que EcuM_Shutdown não deve retornar ao chamador [SWS_EcuM_02953]. Após o processamento, a função desliga a ECU definitivamente ou, alternativamente, dispara um reset [SWS_EcuM_02953].

Utilização e contexto de chamada

A função síncrona EcuM_SetState serve para o BswM comunicar uma transição de estado ao EcuM [SWS_EcuM_04122]. Como parâmetro de entrada, é passado state do tipo EcuM_StateType, o qual especifica o estado predefinido pelo BswM [SWS_EcuM_04122]. A função não possui valor de retorno [SWS_EcuM_04122].

Modo de funcionamento e interação

Ao ser chamada, a função define o estado interno do EcuM para o valor do parâmetro state [SWS_EcuM_04123]. Se o BswM definir dessa forma um estado do EcuM, o EcuM indica o modo correspondente à RTE [SWS_EcuM_04116].

Tratamento de erros

Se o valor passado do parâmetro state for inválido, EcuM_SetState não altera o estado do EcuM [SWS_EcuM_04123]. Desde que o Development Error Reporting esteja ativado, a função reporta adicionalmente, nesse caso de erro, o erro ECUM_E_STATE_PAR_OUT_OF_RANGE ao módulo DET [SWS_EcuM_04123].

Concorrência e interface

A execução é síncrona e reentrante [SWS_EcuM_04122]. O serviço é declarado por meio do arquivo de cabeçalho EcuM.h [SWS_EcuM_04122].

usar

A função síncrona e reentrante EcuM_RequestRUN serve para solicitar o estado RUN junto ao ECU State Manager [SWS_EcuM_04124]. Como parâmetro, é passado via user do tipo EcuM_UserType o identificador da entidade solicitante; têm permissão exclusivamente os usuários que já foram dados a conhecer ao gerenciador de estados no momento da configuração [SWS_EcuM_04124]. A função retorna E_OK se o EcuM tiver aceitado a solicitação, caso contrário E_NOT_OK [SWS_EcuM_04124]. O serviço é declarado por meio do cabeçalho EcuM.h [SWS_EcuM_04124].

Tratamento de erros e restrições

As solicitações não podem ser aninhadas: um usuário individual pode manter no máximo uma solicitação de RUN ativa a qualquer momento [SWS_EcuM_04125]. Se EcuM_RequestRUN detectar chamadas repetidas ou duplicadas pelo mesmo usuário, o código de erro ECUM_E_MULTIPLE_RUN_REQUESTS será reportado ao DET se a detecção de erros de desenvolvimento estiver ativada [SWS_EcuM_03024], [SWS_EcuM_04125].

Interação

Cada solicitação de estado definida com sucesso por meio de EcuM_RequestRUN deve ser liberada novamente após a conclusão da atividade. Para isso, está disponível o serviço complementar, também síncrono e reentrante, EcuM_ReleaseRUN, ao qual é passado o mesmo ID de usuário [SWS_EcuM_04127].

usar

A função síncrona EcuM_ReleaseRUN (ID de serviço 0x04) destina-se à liberação de uma solicitação de estado RUN previamente registada através de EcuM_RequestRUN [SWS_EcuM_04127]. A interface é disponibilizada através do cabeçalho EcuM.h e está primariamente prevista para a implementação de portas AUTOSAR [SWS_EcuM_04127]. Como parâmetro de entrada, a função espera o identificador de utilizador user do tipo EcuM_UserType, o qual identifica univocamente a entidade que efetua a liberação dentro do módulo [SWS_EcuM_04127].

O valor de retorno do tipo Std_ReturnType sinaliza com E_OK que a solicitação de liberação foi aceite com sucesso pelo módulo [SWS_EcuM_04127]. Se a liberação não pôde ser processada, o serviço retorna o valor de erro E_NOT_OK [SWS_EcuM_04127].

Tratamento de erros e simultaneidade

Códigos de erro específicos, erros de desenvolvimento (DET) ou erros de produção (DEM) não são listados na especificação; a rejeição de uma solicitação manifesta-se exclusivamente através do retorno de E_NOT_OK [SWS_EcuM_04127]. É de presumir (interpretação:) que um retorno de E_NOT_OK ocorra presumivelmente quando não existe nenhuma solicitação ativa para o ID de utilizador indicado ou quando foi passado um valor de parâmetro inválido. Pergunta Q-cbe9031cffe1be81 (aberta)

A função está declarada como reentrante, podendo, por isso, ser chamada em contextos de execução concorrentes [SWS_EcuM_04127]. Como pré-requisito de ordem funcional, a chamada requer obrigatoriamente que o respetivo utilizador tenha previamente solicitado o estado através de EcuM_RequestRUN [SWS_EcuM_04127].

Interação

O módulo EcuM disponibiliza este serviço para terminar a manutenção do estado RUN através de portas definidas [SWS_EcuM_04127]. Para a configuração do RTE e a interação com o comportamento de tempo de execução local do RTE, a especificação define o comportamento interno do EcuStateManager com múltiplas Runnable Entities executáveis concorrentemente [SWS_EcuM_03018].

usar

A função síncrona EcuM_RequestPOST_RUN serve para solicitar o estado POST RUN junto ao ECU State Manager ([SWS_EcuM_04128]). O chamador se identifica por meio do parâmetro user, devendo cada entidade solicitante já ter sido dada a conhecer ao gerenciador de estados no momento da configuração ([SWS_EcuM_04128]). O serviço é declarado no cabeçalho EcuM.h, previsto para a implementação de portas AUTOSAR e confirma uma aceitação bem-sucedida com E_OK ou uma rejeição com E_NOT_OK ([SWS_EcuM_04128]).

Tratamento de erros

Desde que a detecção de erros de desenvolvimento esteja ativada, uma nova chamada pelo mesmo usuário faz com que EcuM_RequestPOST_RUN reporte o erro ECUM_E_MULTIPLE_RUN_REQUESTS ao DET ([SWS_EcuM_03025]). Interpretação: no caso de tais solicitações múltiplas ou de IDs de usuário inválidos, é provável que o serviço responda com E_NOT_OK ([SWS_EcuM_04128]). Pergunta Q-b5bbd7d5b53e76ba (aberta)

Concorrência e interação

A função é projetada para ser reentrante ([SWS_EcuM_04128]). No módulo, as solicitações para RUN e POST RUN devem ser rastreadas de forma estritamente independente uma da outra por meio de duas variáveis distintas ([SWS_EcuM_04128]). Cada solicitação registrada por meio deste serviço mantém o estado POST RUN ativo até ser explicitamente revogada pela chamada complementar de EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]).

Utilização e semântica

A função síncrona e reentrante EcuM_ReleasePOST_RUN ([SWS_EcuM_04129]) serve para liberar uma solicitação de POST-RUN previamente definida por meio de EcuM_RequestPOST_RUN. Através do parâmetro de entrada user do tipo EcuM_UserType, é passado o identificador da entidade que libera novamente o estado de POST-RUN. A interface está disponível através do ficheiro de cabeçalho EcuM.h e foi concebida primariamente para a realização de portas AUTOSAR ([SWS_EcuM_04129]).

Valores de retorno e tratamento de erros

A função retorna o estado Std_ReturnType ([SWS_EcuM_04129]):

• E_OK: a solicitação de liberação foi aceite com sucesso pelo ECU State Manager.
• E_NOT_OK: a solicitação de liberação foi rejeitada. Interpretação: presume-se que ocorra uma rejeição com E_NOT_OK se não houver nenhuma solicitação ativa registada para o utilizador indicado ou se tiver sido passado um identificador de utilizador inválido. Pergunta Q-67bd8594612defca (aberta)

Concorrência e interação

O serviço está especificado como reentrante ([SWS_EcuM_04129]), pelo que são permitidas chamadas simultâneas por várias entidades. A função é parte integrante do comportamento interno do módulo EcuM ([SWS_EcuM_03018]). A chamada pressupõe logicamente que a entidade tenha solicitado previamente a fase POST RUN ([SWS_EcuM_04129]). Interpretação: tipicamente, a chamada deverá ocorrer a partir de componentes de software através de portas RTE assim que as suas atividades de pós-operação estiverem concluídas antes do desligamento. Pergunta Q-81f71656d4debb4a (aberta)

A função de serviço síncrona EcuM_SelectShutdownTarget serve para selecionar o destino de shutdown para a ECU e é disponibilizada por meio do arquivo de cabeçalho EcuM.h bem como parte da port interface do módulo ECU Manager [SWS_EcuM_02822]. Através da chamada, o destino de shutdown interno é definido para o valor do parâmetro passado shutdownTarget [SWS_EcuM_00624].

A função espera dois parâmetros de entrada [SWS_EcuM_02822]:

• shutdownTarget: determina o destino selecionado para o desligamento [SWS_EcuM_02822].
• shutdownMode: contém o identificador de um modo sleep (se o destino for ECUM_SHUTDOWN_TARGET_SLEEP) ou de um mecanismo de reset (se o destino for ECUM_SHUTDOWN_TARGET_RESET) conforme a configuração [SWS_EcuM_02822].

A chamada não inicia atividades imediatas de configuração ou execução (setup), apenas armazena os valores para uso posterior na fase SHUTDOWN ou SLEEP [SWS_EcuM_02585].

No que diz respeito à concorrência, a função é especificada como reentrante [SWS_EcuM_02822]. No RTE Internal Behavior do ECU State Manager, a Runnable Entity correspondente SelectShutdownTarget é declarada com canbeInvokedConcurrently = TRUE [SWS_EcuM_03018], permitindo assim chamadas paralelas.

O valor de retorno do tipo Std_ReturnType sinaliza com E_OK que o novo destino de shutdown foi definido com sucesso e com E_NOT_OK que a adoção falhou [SWS_EcuM_02822]. A especificação não menciona neste ponto causas concretas de falha para E_NOT_OK ou mensagens de DET; presumivelmente, combinações inválidas ou não configuradas de destino e modo levam à rejeição. Pergunta Q-e916f3a6ac0bf47e (aberta)

A função síncrona EcuM_SelectShutdownCause serve para a seleção da causa para um desligamento da ECU e está disponível por meio do arquivo de cabeçalho EcuM.h [SWS_EcuM_04050].

Uso e semântica:

• Parâmetro: O parâmetro de entrada target do tipo EcuM_ShutdownCauseType passa a causa de desligamento selecionada [SWS_EcuM_04050].
• Valor de retorno: Um valor de retorno do tipo Std_ReturnType sinaliza com E_OK que a nova causa foi definida com sucesso e com E_NOT_OK que a definição falhou [SWS_EcuM_04050].
• Execução: O serviço opera de forma síncrona sob o ID de serviço 0x1b e é especificado como reentrante [SWS_EcuM_04050].

Concorrência e interação:

A função é parte da interface de porta do módulo ECU Manager [SWS_EcuM_04050]. Para a configuração da RTE local, no comportamento interno EcuStateManager, está definida a Runnable Entity SelectShutdownCause com o símbolo EcuM_SelectShutdownCause, sendo atribuída a propriedade canbeInvokedConcurrently = TRUE [SWS_EcuM_03018].

Tratamento de erros:

No escopo da especificação não são indicadas mensagens específicas de DET ou DEM; estados de erro ao definir a causa são indicados exclusivamente por meio do valor de retorno E_NOT_OK [SWS_EcuM_04050].

A função de serviço síncrona EcuM_ClearWakeupEvent (Service-ID 0x16) serve para redefinir eventos de wakeup e está disponível por meio do arquivo de cabeçalho EcuM.h [SWS_EcuM_02828]. Como parâmetro, ela recebe a máscara de bits sources do tipo EcuM_WakeupSourceType e não possui valor de retorno [SWS_EcuM_02828].

Na chamada, todos os eventos pendentes definidos como bit em sources são limpos de três variáveis internas do módulo [SWS_EcuM_02683]:

• da variável interna para eventos de wakeup pendentes (pending wakeup events),
• da variável interna para eventos de wakeup validados (validated events), bem como
• da variável interna para eventos de wakeup expirados (expired events) [SWS_EcuM_02683].

Em relação ao contexto de chamada, EcuM_ClearWakeupEvent pode ser chamada de forma flexível a partir do contexto de interrupção, do contexto regular de OS, bem como de um contexto sem OS [SWS_EcuM_02807]. Ao mesmo tempo, porém, a função é obrigatoriamente especificada como não reentrante (Non-Reentrant) e não interrompível (Non-Interruptible) [SWS_EcuM_02828]. Interpretação: Como a função é permitida em diferentes contextos, mas não é interrompível, o integrador ou chamador provavelmente deve garantir de forma organizacional que não ocorram chamadas simultâneas ou que interrompam umas às outras. Pergunta Q-71a4b1b218505a1c (aberta)

A função síncrona EcuM_AbortWakeupAlarm serve para cancelar um alarme de wakeup previamente definido por um usuário [SWS_EcuM_04061]. A interface está disponível através do arquivo de cabeçalho EcuM.h e faz parte da interface de portas do módulo ECU Manager [SWS_EcuM_04061].

Parâmetros e valores de retorno

• user (In): Identificador do usuário do tipo EcuM_UserType que deseja cancelar o alarme de wakeup [SWS_EcuM_04061]. Não existem parâmetros de entrada/saída ou puramente de saída [SWS_EcuM_04061].
• E_OK: O serviço foi executado com sucesso e o alarme foi cancelado [SWS_EcuM_04061].
• ECUM_E_NOT_ACTIVE: Não foi encontrado nenhum alarme ativo pertencente ao usuário passado [SWS_EcuM_04061].
• E_NOT_OK: A execução do serviço falhou [SWS_EcuM_04061].

Concorrência e interação

A função possui o Service ID 0x24 e está especificada como reentrante [SWS_EcuM_04061]. As chamadas podem, portanto, ocorrer de forma concorrente para diferentes usuários. O comportamento interno do ECU Manager define as unidades executáveis para a configuração da RTE local [SWS_EcuM_03018]; como parte da interface de portas do módulo, a chamada normalmente deve ser iniciada por componentes de software através da RTE. Pergunta Q-2c8f004d9f00bbd3 (aberta)

A função síncrona e reentrante EcuM_SetClock serve, de acordo com [SWS_EcuM_04064], para definir o horário interno do ECU State Manager para um valor predeterminado. Como parte da interface de porta do ECU Manager, a função pode ser integrada e chamada por meio do arquivo de cabeçalho EcuM.h [SWS_EcuM_04064].

A principal finalidade de aplicação da interface é o teste de serviços de alarme: alarmes cujo decurso regular levaria dias podem ser verificados definindo propositalmente o horário em operação de teste [SWS_EcuM_04064]. Aqui são passados dois parâmetros de entrada:

• user (tipo EcuM_UserType): identificador do chamador ou usuário que deseja definir o horário.
• time (tipo EcuM_TimeType): indicação de tempo absoluto em segundos desde a conexão da bateria (Battery Connect).

Como valor de retorno, o serviço fornece o status Std_ReturnType com E_OK em caso de execução bem-sucedida ou E_NOT_OK em caso de erro [SWS_EcuM_04064]. Causas de erro concretas ou mensagens de DET não são especificadas na interface; provavelmente a passagem de identificadores de usuário não autorizados ou valores de tempo inválidos leva ao retorno de E_NOT_OK. Pergunta Q-248768580c0309e8 (aberta)

Em relação ao comportamento interno do módulo e à configuração da RTE, a função integra-se à estrutura das Runnable Entities do EcuStateManager [SWS_EcuM_03018].

A função síncrona EcuM_SelectBootTarget serve para a seleção de um Boot Target para a ECU e faz parte da interface de porta do ECU Manager, além de estar disponível por meio do cabeçalho EcuM.h [SWS_EcuM_02835]. O alvo desejado é passado por meio do parâmetro de entrada target do tipo EcuM_BootTargetType [SWS_EcuM_02835].

Como valor de retorno, a função sinaliza E_OK se o novo Boot Target tiver sido aceito pelo EcuM; caso contrário, E_NOT_OK [SWS_EcuM_02835]. A implementação deve salvar o alvo selecionado de maneira compatível com o bootloader [SWS_EcuM_02247]. O valor atualmente definido pode ser consultado por meio do serviço complementar EcuM_GetBootTarget [SWS_EcuM_02836].

A função é especificada como reentrante [SWS_EcuM_02835]; no âmbito do comportamento interno para a configuração de RTE, a Runnable Entity SelectBootTarget é declarada com canbeInvokedConcurrently = TRUE [SWS_EcuM_03018]. Como restrição, este serviço destina-se exclusivamente a componentes de software (SW-Cs) relacionados a diagnóstico ou gerenciamento de boot, podendo depender do bootloader concretamente utilizado [SWS_EcuM_03000].

EcuM_ValidateWakeupEvent é um serviço síncrono (Service-ID 0x14) que sinaliza ao ECU Manager que as fontes de despertar passadas no parâmetro sources foram validadas com sucesso ([SWS_EcuM_02829]). Após o despertar, o ECU State Manager aguarda essa confirmação na sequência de validação. Ao ser chamada, a função para o temporizador de timeout de validação em execução ([SWS_EcuM_02710]) e insere os eventos passados por meio de uma operação OR na máscara de bits na variável interna para eventos de despertar validados ([SWS_EcuM_04078]).

A função é reentrante ([SWS_EcuM_02829]) e pode ser chamada tanto a partir do contexto de tarefa quanto do contexto de interrupção ([SWS_EcuM_02345]). Se o ECU Manager se encontrar no estado RUN, a chamada não surtirá efeito para nenhuma fonte de despertar, a menos que se trate de canais de comunicação ([SWS_EcuM_02790]). Já para fontes atribuídas a um canal de comunicação, o serviço produz efeito irrestrito em qualquer fase da ECU ([SWS_EcuM_02791]).

No fluxo global, o serviço interage estreitamente com a validação de despertar e com o gerenciamento de comunicação:

• Verificação de validação: Para a verificação, o ECU Manager chama o callout EcuM_CheckValidation; se for detectado um evento de despertar válido, o retorno ocorre por meio de EcuM_ValidateWakeupEvent ([SWS_EcuM_02925]).
• Configuração: Se nenhum protocolo de validação estiver configurado para uma fonte de despertar (EcuMValidationTimeout), EcuM_SetWakeupEvent já implica a chamada de EcuM_ValidateWakeupEvent ([SWS_EcuM_02566]).
• Notificação: Se EcuMComMChannelRef estiver configurado para a fonte de despertar, o serviço chama ComM_EcuM_WakeUpIndication ([SWS_EcuM_02645]). Com EcuMComMPNCRef configurado, ComM_EcuM_PNCWakeUpIndication também é disparado para cada PNC referenciado ([SWS_EcuM_04140]).

A função de callback síncrona e não reentrante EcuM_ErrorHook (disponibilizada por meio de EcuM_Externals.h) é chamada pelo ECU State Manager assim que ocorrem erros graves que inviabilizam o processamento posterior regular e exigem a parada da ECU [SWS_EcuM_02904]. A causa de erro específica é transmitida por meio do parâmetro de passagem reason [SWS_EcuM_02904].

Entre as causas de erro definidas estão ECUM_E_RAM_CHECK_FAILED e ECUM_E_CONFIGURATION_DATA_INCONSISTENT [SWS_EcuM_02904]. Se o teste de RAM falhar durante o wakeup, o ECU Manager é obrigado a disparar EcuM_ErrorHook com o motivo ECUM_E_RAM_CHECK_FAILED [SWS_EcuM_02987]. Além disso, o tratamento de erros ocorre por meio deste hook quando uma chamada a uma função do sistema operacional falha e nenhuma outra reação a erros estiver especificada; nesse caso, o EcuM permanece no estado anterior [SWS_EcuM_04139].

Para o integrador do sistema aplicam-se as seguintes condições de contorno na implementação:

• Modalidade de parada da ECU: O integrador escolhe a forma como a ECU é desativada (por exemplo, reset, halt, reinicialização ou estado seguro) [SWS_EcuM_02904]. Interpretação: Em medidas drásticas, como um reset ou halt, a função provavelmente não deve mais retornar ao fluxo de controle regular. Pergunta Q-59c23e3a2569f670 (aberta)
• Notificação de erro ao DEM: Fica a critério do integrador se o erro é encaminhado ao DEM, desde que se assegure que o DEM não grave em blocos corrompidos de NVRAM [SWS_EcuM_02987].

Uso e condições de chamada

A função de callout EcuM_AL_SetProgrammableInterrupts é chamada pelo módulo ECU State Manager para configurar e definir as interrupções correspondentes em ECUs com controladores de interrupção programáveis [SWS_EcuM_04085]. A execução deste callout, no entanto, ocorre apenas se o parâmetro de configuração EcuMSetProgrammableInterrupts estiver definido com o valor true [SWS_EcuM_04085]. Se este parâmetro não estiver ativado, a chamada não ocorre [SWS_EcuM_04085]. Para integradores e drivers de plataforma, a declaração da interface é disponibilizada através do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_04085].

A interface possui a sintaxe void EcuM_AL_SetProgrammableInterrupts (void) e está atribuída ao Service-ID 0x4A [SWS_EcuM_04085]. A chamada ocorre totalmente sem parâmetros: não são passados parâmetros de entrada, de entrada/saída ou de saída, e a função não retorna nenhum valor de retorno ao módulo chamador [SWS_EcuM_04085].

Simultaneidade e restrições

Para EcuM_AL_SetProgrammableInterrupts, está definido na especificação um comportamento de execução assíncrono (Asynchronous) [SWS_EcuM_04085]. Em relação à simultaneidade, a função é classificada como não reentrante (Non Reentrant) [SWS_EcuM_04085]. Para a integração, isso significa que chamadas paralelas ou aninhadas da interface são inadmissíveis e a configuração relacionada a interrupções deve ocorrer sem reentrâncias simultâneas [SWS_EcuM_04085].

usar

A função de callout EcuM_AL_DriverInitZero (Service-ID 0x31) é chamada de forma síncrona, não possui parâmetros nem valor de retorno e é não reentrante [SWS_EcuM_02905]. Ela é declarada por meio do cabeçalho EcuM_Externals.h [SWS_EcuM_02905]. A função serve para fornecer inicializações iniciais de drivers, bem como atividades fundamentais de inicialização relacionadas ao hardware, que são estritamente necessárias para subsequentemente poder carregar os dados de configuração Post-Build [SWS_EcuM_02905].

Restrições e operação multi-core

Para a implementação e execução aplicam-se diretrizes e restrições específicas:

• Classes de configuração: Neste momento inicial, só podem ser utilizados módulos configuráveis como Pre-Compile ou Link-Time [SWS_EcuM_02905]. Drivers configuráveis como Post-Build ainda não estão disponíveis aqui.
• Contexto de chamada: A função é chamada por EcuM_Init em cada Core do sistema [SWS_EcuM_04145].
• Inicialização específica de Core: A implementação do callout deve assegurar que no Core atualmente ativo sejam inicializados apenas os módulos MCAL que são efetivamente executados neste Core específico [SWS_EcuM_04145].

Valores de retorno, códigos de erro específicos ou notificações via DET ou DEM não estão definidos para este callout [SWS_EcuM_02905].

A função EcuM_DeterminePbConfiguration ([SWS_EcuM_02906]) é um callout síncrono do ECU State Manager, que é disponibilizado por meio do arquivo de cabeçalho EcuM_Externals.h e possui o ID de serviço 0x32. A interface não possui parâmetros de entrada, de saída nem de entrada/saída ([SWS_EcuM_02906]). Sua finalidade central consiste em definir, durante o processo de inicialização, com base em condições de hardware ou de memória, qual conjunto de dados de configuração post-build deve ser utilizado para o andamento posterior da inicialização do sistema ([SWS_EcuM_02906]).

Para determinar a configuração, o callout deve avaliar critérios externos ou residentes, como o status de um pino de porta ou um valor na NVRAM ([SWS_EcuM_02906]). Em seguida, a função deve carregar esses dados de configuração em um segmento de memória acessível por todos os módulos BSW ([SWS_EcuM_02906]). Como valor de retorno, ela retorna um ponteiro do tipo const EcuM_ConfigType* para a configuração post-build do EcuM ([SWS_EcuM_02906]). Esse ponteiro forma a base inicial comum para todo o BSW, uma vez que a estrutura contém ponteiros para as respectivas configurações post-build de todos os demais módulos BSW ([SWS_EcuM_02906]).

Quanto ao comportamento de chamada, a função é especificada como síncrona e não reentrante (Non Reentrant) ([SWS_EcuM_02906]). Códigos de erro específicos, valores de retorno de erro especiais, bem como interfaces para DET ou DEM não estão definidos para este callout ([SWS_EcuM_02906]). Portanto, deve-se considerar como interpretação das diretrizes que uma implementação de callout específica da aplicação precisa tratar estados de erro de forma independente, pois a ausência de um ponteiro de configuração válido provavelmente impediria a inicialização ordenada dos módulos BSW dependentes. Pergunta Q-b9487647fb39a2e2 (aberta)

Utilização e semântica

A função EcuM_AL_DriverInitOne é uma função de callout do gestor de estados da ECU (EcuM), fornecida através do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_02907]. A sua tarefa primária consiste em realizar a inicialização de drivers bem como outras atividades de inicialização da unidade de controle relacionadas ao hardware no caso de um Power-on-Reset [SWS_EcuM_02907]. Como se trata de um callout, a implementação concreta da inicialização de hardware e de drivers provavelmente é realizada pelo respectivo integrador do sistema. Pergunta Q-e22baf2fa31cf075 (aberta)

A interface possui a assinatura C void EcuM_AL_DriverInitOne (void) e está atribuída ao Service ID 0x33 [SWS_EcuM_02907]. Ela não aceita quaisquer parâmetros de entrada e também não retorna nenhum valor de retorno ao chamador [SWS_EcuM_02907].

Simultaneidade e restrições

Para a chamada e o comportamento em tempo de execução aplicam-se, de acordo com [SWS_EcuM_02907], as seguintes condições de contorno:

• Sincronismo: A execução ocorre de forma síncrona (Synchronous), de modo que o chamador aguarda a conclusão das atividades de inicialização.
• Reentrância: A função é definida como não reentrante (Non Reentrant); chamadas múltiplas simultâneas ou interruptivas são inadmissíveis.
• Contexto de chamada: A ativação é especificada exclusivamente para a fase de inicialização imediatamente após um Power-on-Reset.

Tratamento de erros

Como EcuM_AL_DriverInitOne apresenta o tipo de retorno void, não existe no nível da interface nenhum feedback direto sobre o sucesso ou falha da inicialização [SWS_EcuM_02907]. Códigos de erro específicos, mensagens de DET ou DEM não estão definidos no presente escopo da especificação para este callout.

A função EcuM_LoopDetection é um callout do ECU State Manager com o Service ID 0x4B, disponibilizado através do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_04137].

Utilização e contexto de chamada

Desde que o parâmetro de configuração EcuMResetLoopDetection esteja definido como true, este callout é chamado de forma síncrona a cada inicialização (Startup) [SWS_EcuM_04137]. A função não possui parâmetros de entrada, de entrada/saída nem de saída e não retorna nenhum valor de retorno (assinatura: void EcuM_LoopDetection (void)) [SWS_EcuM_04137].

Simultaneidade e restrições

A execução de EcuM_LoopDetection está especificada como síncrona e não reentrante (Non Reentrant) [SWS_EcuM_04137]. Como se trata de um callout, a implementação concreta da detecção de loops cabe tipicamente ao integrador ou usuário, a fim de registrar loops de reset repetidos durante a inicialização do sistema.

usar

A função EcuM_OnGoOffOne serve para anunciar que o estado do sistema GO OFF I foi atingido e dar ao projetista do sistema a possibilidade de adotar medidas correspondentes imediatamente antes da transição [SWS_EcuM_02916]. A função é executada de forma síncrona, não espera parâmetros de passagem (nem in nem inout) e não retorna nenhum valor de retorno (void) [SWS_EcuM_02916]. Como a interface é declarada através do arquivo de cabeçalho EcuM_Externals.h, é plausível que se trate de uma função de callout específica do usuário, implementada no código de integração [SWS_EcuM_02916]. Pergunta Q-93de53c47a5a6142 (aberta)

Tratamento de erros

Na especificação de EcuM_OnGoOffOne, não estão listados erros de desenvolvimento (DET), erros de produção (DEM) ou valores específicos de retorno de erro [SWS_EcuM_02916]. Disso pode-se concluir que o chamador não espera um gerenciamento de erros padronizado e eventuais casos excepcionais devem ser tratados de forma autônoma dentro da implementação específica do usuário [SWS_EcuM_02916].

Simultaneidade e restrições

Para o contexto de chamada e o comportamento em tempo de execução, estão definidas as seguintes propriedades [SWS_EcuM_02916]:

• Reentrância: a função está especificada como não reentrante (Non Reentrant) e não deve de forma alguma ser chamada em paralelo ou de maneira aninhada [SWS_EcuM_02916].
• Sincronismo: a semântica é estritamente síncrona (Synchronous), de modo que o chamador aguarda o retorno completo da função [SWS_EcuM_02916].
• Service-ID: o serviço é representado internamente pelo identificador hexadecimal 0x3C [SWS_EcuM_02916].

Devido ao comportamento síncrono e à transição iminente para o estado GO OFF I, presume-se que operações bloqueantes devam ser evitadas para não atrasar indevidamente o processo de desligamento ou transição [SWS_EcuM_02916]. Pergunta Q-93f5e23c581f0c38 (aberta)

A função síncrona EcuM_OnGoOffTwo serve, de acordo com a especificação, para permitir ao projetista do sistema a notificação de que o estado GO OFF II está iminente [SWS_EcuM_02917]. A chamada é feita sem parâmetros de entrada, entrada/saída ou saída (sem parâmetros In, Inout ou Out) e não devolve nenhum valor de retorno ao chamador [SWS_EcuM_02917].

Em relação ao contexto de execução e à concorrência, a interface está provida do Service ID 0x3D e especificada como não reentrante (Non Reentrant) [SWS_EcuM_02917]. Ela é disponibilizada através do cabeçalho EcuM_Externals.h [SWS_EcuM_02917]. Interpretação: Como a declaração se encontra em EcuM_Externals.h e serve para a notificação do projetista do sistema, a função provavelmente foi concebida como um callout síncrono do gerenciamento da ECU, chamado antes da transição para o estado GO OFF II. Pergunta Q-bb0ae6e4632de827 (aberta)

Devido à característica de interface não reentrante, a chamada não pode ser repetida de forma paralela ou interruptiva [SWS_EcuM_02917]. Códigos de erro específicos, confirmações para DET ou DEM, bem como mecanismos dedicados de tratamento de erros, não estão definidos no escopo da especificação [SWS_EcuM_02917].

usar

A função de callout EcuM_AL_SwitchOff faz parte do módulo ECU State Manager (EcuM) e serve para acomodar o código específico do usuário para o desligamento da alimentação de tensão da ECU [SWS_EcuM_02920]. A interface está definida como síncrona, possui o Service ID 0x3E e é fornecida através do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_02920].

De acordo com a especificação, a função não recebe parâmetros de entrada, de entrada/saída nem de saída e não possui valor de retorno (void) [SWS_EcuM_02920]. Se o hardware da ECU não puder desenergizar-se de forma autônoma, a especificação prevê que o acionamento de um reset pode constituir, em alternativa, uma reação adequada [SWS_EcuM_02920].

Interação e concorrência

A chamada de EcuM_AL_SwitchOff é realizada obrigatoriamente pelo módulo ECU Manager logo que o destino de shutdown selecionado seja OFF [SWS_EcuM_04075]. Em relação ao comportamento de concorrência, o callout está definido como não reentrante (Non Reentrant) [SWS_EcuM_02920]. Interpretação: Como o objetivo da função é a desconexão completa da alimentação de energia ou, subsidiariamente, um reset, este callout provavelmente representa o passo final da sequência de desligamento, após o qual não ocorre mais nenhuma execução regular de programa. Pergunta Q-e8a1aaa1413bbea9 (aberta)

Tratamento de erros

Para o callout, não estão previstos na especificação códigos de erro específicos, nem mecanismos de tratamento de erro ou mensagens para DET ou DEM [SWS_EcuM_02920].

O callout EcuM_AL_Reset serve para acomodar o código específico de integração responsável por reiniciar a ECU ([SWS_EcuM_04065]). A interface é declarada através do arquivo de cabeçalho EcuM_Externals.h e possui o Service ID 0x4C ([SWS_EcuM_04065]).

A chamada da função ocorre de forma síncrona e é definida como não reentrante (Non Reentrant) ([SWS_EcuM_04065]). Como único parâmetro de entrada é passado reset do tipo EcuM_ResetType, que determina o tipo concreto de reset a ser executado ([SWS_EcuM_04065]). A função não possui valor de retorno (void) e não dispõe de parâmetros de saída ou de entrada/saída ([SWS_EcuM_04065]).

Na interação da fase de shutdown, está estabelecido que o módulo ECU Manager deve obrigatoriamente chamar o callout EcuM_AL_Reset quando o destino de desligamento estiver definido como RESET ([SWS_EcuM_04074]). Para o callout, não estão previstos na especificação nem códigos de erro nem notificações para DET ou DEM ([SWS_EcuM_04065]). Interpretação: O callout provavelmente executa comandos de controle de baixo nível que provocam diretamente o reset da MCU. Pergunta Q-1e318404843faabd (aberta)

A função EcuM_EnableWakeupSources é um callout síncrono do gestor da ECU com o Service ID 0x3F, declarado através do cabeçalho EcuM_Externals.h [SWS_EcuM_02918]. Ela serve para informar o desenvolvedor do sistema de que o estado SLEEP está iminente, para que as fontes de wakeup indicadas no campo de bits wakeupSource (tipo EcuM_WakeupSourceType) possam ser devidamente preparadas e configuradas [SWS_EcuM_02918].

Utilização e interação

O gestor da ECU executa EcuM_EnableWakeupSources para configurar as fontes de wakeup para o próximo modo Sleep; isso ocorre para cada fonte de wakeup que esteja configurada em EcuMWakeupSourceMask para o modo Sleep pretendido [SWS_EcuM_02389]. A função não possui valor de retorno (void) e espera como parâmetro de entrada o campo de bits wakeupSource [SWS_EcuM_02918].

Simultaneidade e restrições

• Reentrância: A função é especificada como não reentrante (Non Reentrant) [SWS_EcuM_02918].
• Sincronismo: O processamento ocorre de forma síncrona [SWS_EcuM_02918].
• Tratamento de erros: No escopo da especificação da interface, não estão definidas mensagens de erro específicas de DET ou DEM [SWS_EcuM_02918].

A função EcuM_GenerateRamHash serve para a geração de um valor de verificação de RAM no contexto do ECU State Manager, remetendo a especificação para EcuM_CheckRamHash quanto ao modo de funcionamento [SWS_EcuM_02919]. O valor de verificação gerado serve provavelmente para a posterior verificação de integridade da memória de trabalho em conexão com estados de dormência ou repouso. Pergunta Q-7f316b389e1609c0 (aberta)

Uso e interface

O serviço possui o Service ID 0x40 e a assinatura void EcuM_GenerateRamHash(void) [SWS_EcuM_02919]. A função não possui parâmetros de entrada, de saída nem de entrada/saída e não fornece valor de retorno. A execução ocorre de forma síncrona.

Simultaneidade e restrições

A função está especificada como não reentrante (Non Reentrant) [SWS_EcuM_02919]. Consequentemente, ela não pode ser chamada de forma interruptiva ou paralela a partir de múltiplos contextos. A declaração é fornecida através do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_02919]. Interpretação: Pela definição em EcuM_Externals.h, provavelmente trata-se de um callout a implementar de forma específica pelo usuário, chamado pelo ECU State Manager em um momento oportuno no fluxo de estados. Pergunta Q-2f53f1a19cee079c (aberta)

Tratamento de erros

Para EcuM_GenerateRamHash, não estão definidos em [SWS_EcuM_02919] códigos de erro específicos nem mensagens de DET ou DEM.

Utilização e contexto de chamada

A função EcuM_SleepActivity representa um callout do ECU State Manager, disponibilizado no arquivo de cabeçalho EcuM_Externals.h com o Service-ID 0x41 [SWS_EcuM_02928]. A chamada ocorre periodicamente em todos os modos de sleep com clock de processador reduzido (reduced clock sleep modes) [SWS_EcuM_02928]. A função possui a assinatura void EcuM_SleepActivity(void), opera de forma síncrona e não recebe parâmetros de entrada, de saída ou de entrada/saída [SWS_EcuM_02928].

Tarefas funcionais e interação

A finalidade deste callout é a execução de atividades durante o sono: é explicitamente previsto e permitido consultar ciclicamente fontes de wakeup (polling) dentro de EcuM_SleepActivity [SWS_EcuM_02928]. Além disso, funções de notificação de wakeup podem ser chamadas diretamente a partir do callout para indicar ao ECU State Manager a conclusão do estado de sono [SWS_EcuM_02928].

Simultaneidade e restrições

A interface está especificada como não reentrante (Non Reentrant) [SWS_EcuM_02928]. Como o callout não fornece um valor de retorno e não há parâmetros de erro definidos, não ocorre nenhum tratamento direto de erros através da interface da função por meio de códigos de erro ou notificadores de erro como DET ou DEM [SWS_EcuM_02928].

Utilização e contexto de chamada

A interface síncrona EcuM_StartCheckWakeup é chamada, segundo [SWS_EcuM_04096], pelo firmware da ECU para iniciar o temporizador CheckWakeupTimer para uma determinada fonte de wakeup. Para isso, é passado à função o parâmetro WakeupSource do tipo EcuM_WakeupSourceType. Ela não possui valor de retorno (void) e é disponibilizada através do arquivo de cabeçalho EcuM_Externals.h.

Fluxo e condições

A execução da função depende da configuração da fonte de wakeup [SWS_EcuM_04096]:

• Se para a respectiva fonte de wakeup estiver configurado EcuMCheckWakeupTimeout > 0, o CheckWakeupTimer correspondente é iniciado.
• Se for válido EcuMCheckWakeupTimeout <= 0, a chamada da função é completamente ignorada pelo EcuM.

Simultaneidade e tratamento de erros

A função está especificada como não reentrante (Non Reentrant) [SWS_EcuM_04096]. O chamador deve, portanto, assegurar que chamadas para a mesma ou outras fontes de wakeup não ocorram de forma concorrente. Códigos de erro específicos bem como notificações para DET ou DEM não estão especificados para esta chamada; uma chamada com timeout não positivo permanece sem consequências segundo a especificação, o que provavelmente pode ser interpretado como uma interceptação tolerante de verificações de temporizador irrelevantes [SWS_EcuM_04096]. Pergunta Q-19d98b03d3ee7504 (aberta)

O callout EcuM_CheckWakeup serve para a verificação e o polling de fontes de wakeup, bem como para a configuração da PLL após um evento de wakeup [SWS_EcuM_02929]. A função é fornecida através do arquivo de cabeçalho EcuM_Externals.h e possui o Service ID 0x42 [SWS_EcuM_02929].

Contexto de chamada e semântica

• Assinatura e parâmetros: A função é executada de forma síncrona (Synchronous), não possui valor de retorno e espera como parâmetro de entrada wakeupSource do tipo EcuM_WakeupSourceType [SWS_EcuM_02929].
• Chamador: O callout é chamado por EcuM para consultar ciclicamente uma fonte de wakeup. Além disso, ele deve obrigatoriamente ser chamado pela rotina de serviço de interrupção (ISR) de uma fonte de wakeup a fim de configurar a PLL e verificar outras fontes de wakeup que estejam conectadas à mesma interrupção [SWS_EcuM_02929].
• Loop de polling: Na sequência de polling, o EcuM chama os callouts EcuM_SleepActivity e EcuM_CheckWakeup repetidamente em um loop bloqueante até que um evento de wakeup seja reportado como pendente ou validado [SWS_EcuM_03020].

Restrições e tratamento de erros

A função está especificada como não reentrante (Non Reentrant) [SWS_EcuM_02929]. Como as chamadas ocorrem tanto a partir do fluxo bloqueante da sequência de polling quanto a partir de contextos de ISR, a integração provavelmente deve assegurar que não ocorram chamadas simultâneas não coordenadas. Pergunta Q-8bc8f164670a0911 (aberta) Códigos de erro específicos ou notificações de erro para DET ou DEM não estão definidos para este callout.

A função síncrona EcuM_EndCheckWakeup é chamada por módulos de software quando a verificação assíncrona de uma fonte de despertar (como em um driver de transceptor CAN assíncrono) fornece um resultado negativo, ou seja, nenhum evento de despertar está presente por meio dessa fonte [SWS_EcuM_02927].

Utilização e parâmetros

Por meio do parâmetro de entrada WakeupSource do tipo EcuM_WakeupSourceType, é passada a fonte de despertar para a qual o temporizador de monitoramento associado deve ser cancelado [SWS_EcuM_02927]. A função não retorna valor de retorno (void) e não possui parâmetros de entrada/saída ou de saída [SWS_EcuM_02927].

Funcionamento e concorrência

• A função cancela o temporizador CheckWakeupTimer para a fonte de despertar especificada; com o cancelamento desse temporizador, a verificação da fonte de despertar é considerada concluída [SWS_EcuM_02927].
• A interface é definida como síncrona e não reentrante (Non Reentrant) [SWS_EcuM_02927].
• A declaração é disponibilizada por meio do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_02927].

A função EcuM_CheckRamHash é um callout síncrono e não reentrante (declarado em EcuM_Externals.h) que fornece um teste de integridade da memória RAM [SWS_EcuM_02921]. A função não possui parâmetros e retorna um valor de status do tipo uint8: o valor 0 sinaliza uma falha do teste, enquanto qualquer outro valor indica uma aprovação com sucesso [SWS_EcuM_02921].

De acordo com [SWS_EcuM_02863], o módulo EcuM chama primeiramente [SWS_EcuM_02919] antes de suspender o microcontrolador e executa EcuM_CheckRamHash após o retorno do estado Halt. O objetivo é a verificação de que o conteúdo da RAM permaneceu consistente mesmo após uma longa fase de SLEEP [SWS_EcuM_02921].

Para a implementação e o fluxo aplicam-se as seguintes condições de contorno:

• Algoritmo e área de teste: A função de teste é disponibilizada pelo projetista do sistema; ela não precisa ser exaustiva, mas deve ser executada com rapidez e detectar erros com segurança suficiente [SWS_EcuM_02921]. As áreas a serem verificadas devem ser escolhidas criteriosamente; o conteúdo da pilha (stack) da task em execução geralmente não pode ser verificado [SWS_EcuM_02921].
• Estrutura de tasks: Considera-se uma boa prática recomendada executar a geração e a verificação do hash na mesma task não interrompível, com o mínimo de atividade intermediária [SWS_EcuM_02921].
• Multi-Core: Em múltiplos núcleos de processamento com EcuMs satélites, o callout é chamado exclusivamente pelo EcuM mestre e verifica apenas dados dentro do seu alcance [SWS_EcuM_02863], [SWS_EcuM_02921].

Mensagens específicas de DET ou DEM não estão definidas para este callout; a reação de erro no valor de retorno 0 deve ficar presumivelmente a critério do design do sistema de nível superior [SWS_EcuM_02921]. Pergunta Q-473ef8617db29fe3 (aberta)

A interface síncrona EcuM_DisableWakeupSources com o ID de serviço 0x44 serve para configurar as fontes de despertar definidas no parâmetro de campo de bits wakeupSource do tipo EcuM_WakeupSourceType de modo que elas não possam mais despertar a ECU [SWS_EcuM_02922]. A assinatura da função é void EcuM_DisableWakeupSources (EcuM_WakeupSourceType wakeupSource) [SWS_EcuM_02922].

Para o contexto de chamada e a integração, aplicam-se as seguintes propriedades de acordo com a especificação:

• Chamador e cabeçalho: A função é chamada pelo módulo ECU Manager e disponibilizada por meio do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_02922].
• Parâmetros e valores de retorno: Como único parâmetro de entrada, é passado o campo de bits wakeupSource. A função não possui parâmetros de entrada/saída nem de saída e não retorna valor de retorno (void) [SWS_EcuM_02922].
• Semântica de execução e concorrência: O processamento ocorre de forma síncrona. Além disso, a função é especificada como não reentrante (Non Reentrant), de modo que chamadas simultâneas ou aninhadas devem ser evitadas [SWS_EcuM_02922].

Em relação ao tratamento de erros, a especificação para esta chamada de função não contém códigos de erro específicos nem notificações ao DET ou DEM [SWS_EcuM_02922].

O callout EcuM_AL_DriverRestart é declarado através do arquivo de cabeçalho EcuM_Externals.h e possui o Service ID 0x45 [SWS_EcuM_02923]. A função possui a assinatura void EcuM_AL_DriverRestart (void), não requer parâmetros de transferência e não fornece nenhum valor de retorno [SWS_EcuM_02923]. O objetivo desta interface é fornecer, no caso de wakeup (Wakeup Case), a inicialização de drivers bem como outras atividades relacionadas ao hardware durante a fase de partida [SWS_EcuM_02923].

Para a integração e a interação com o módulo EcuM, aplicam-se diretrizes obrigatórias:

• Para a reinicialização durante a fase WakeupRestart, o integrador deve incluir um bloco de reinício no código de integração para EcuM_AL_DriverRestart, o qual utiliza a lista configurada EcuMDriverRestartList [SWS_EcuM_02947] [SWS_EcuM_02923].
• A lista EcuMDriverRestartList pode conter drivers que atuam como fontes de wakeup (Wakeup Sources) [SWS_EcuM_02562]. Neste caso, EcuM_AL_DriverRestart deve rearmar (re-arm) o mecanismo de acionamento do callback de detecção de wakeup («wakeup detected») desses drivers [SWS_EcuM_02562].

Em relação ao comportamento em tempo de execução, a função está definida como síncrona e não reentrante [SWS_EcuM_02923]. Como se trata de código de integração específico da aplicação, a especificação não define nesta interface códigos de erro próprios nem mensagens padronizadas para DET ou DEM.

A função de callout EcuM_StartWakeupSources serve para iniciar e colocar em operação a(s) fonte(s) de wakeup transmitida(s), de modo que fiquem preparadas para a realização subsequente da validação de wakeup (Wakeup Validation) [SWS_EcuM_02924].

Utilização e contexto de chamada

A função é especificada como uma chamada síncrona com o Service ID 0x46, não possui valor de retorno (void) e é disponibilizada através do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_02924].

• Parâmetro wakeupSource (in): Passa para a função de callout a fonte de wakeup a ser iniciada ou uma máscara de bits de múltiplas fontes de wakeup do tipo EcuM_WakeupSourceType [SWS_EcuM_02924]. Não existem parâmetros adicionais de entrada ou de saída (inout/out) [SWS_EcuM_02924].

Simultaneidade e restrições

Em relação ao ambiente de execução, EcuM_StartWakeupSources está classificada como não reentrante (Non Reentrant) [SWS_EcuM_02924]. Os chamadores devem, portanto, assegurar que a função não seja executada simultaneamente a partir de rotinas de serviço de interrupção (ISR) interruptivas ou tarefas paralelas.

Interação e tratamento de erros

Como EcuM_StartWakeupSources está declarada como callout, a ativação em nível de hardware das fontes afetadas cabe à implementação específica da aplicação por parte do integrador do sistema [SWS_EcuM_02924]. A especificação não prevê para esta interface mensagens de erro para DET ou DEM nem valores de retorno de erro específicos [SWS_EcuM_02924]; eventuais estados de erro ao iniciar as fontes devem, portanto, ser presumivelmente interceptados de modo específico à integração dentro do callout. Pergunta Q-b595e7175c34a831 (aberta)

A função EcuM_CheckValidation serve como interface de callout do ECU State Manager para a verificação de uma fonte de despertar [SWS_EcuM_02925]. O EcuM chama esta função para determinar se um evento de despertar detectado é válido [SWS_EcuM_02925].

usar

O callout possui o Service ID 0x47 e é disponibilizado por meio do arquivo de cabeçalho EcuM_Externals.h [SWS_EcuM_02925]. Como parâmetro de entrada serve wakeupSource do tipo EcuM_WakeupSourceType, por meio do qual é identificada a fonte de despertar a ser validada [SWS_EcuM_02925]. A função não fornece valor de retorno (void) e não possui parâmetros de saída ou de entrada/saída [SWS_EcuM_02925]. A execução ocorre de forma síncrona [SWS_EcuM_02925].

Tratamento de erros

Códigos de erro específicos, valores de retorno em caso de falha ou mensagens para o DET ou DEM não estão definidos na especificação para este callout.

Simultaneidade e restrições

Em relação à concorrência, EcuM_CheckValidation está definida como não reentrante (Non Reentrant) [SWS_EcuM_02925]. O contexto chamador do EcuM deve assegurar que não ocorram chamadas paralelas ou aninhadas para a mesma fonte de despertar ou para fontes distintas.

Interação

Se durante a execução for detetado um evento de despertar válido, este deve ser obrigatoriamente reportado ao EcuM através da chamada de função EcuM_ValidateWakeupEvent() [SWS_EcuM_02925]. Interpretação: presume-se que a lógica específica do dispositivo para verificação do hardware, bem como a decisão sobre a validade, sejam totalmente implementadas no código de integração. Pergunta Q-08061e09b474728d (aberta)

A função de callout EcuM_StopWakeupSources do módulo EcuM (Classic Platform) serve para parar especificamente a(s) fonte(s) de wakeup passada(s) após uma validação de wakeup sem sucesso [SWS_EcuM_02926]. A declaração desta interface síncrona está disponível através do arquivo de cabeçalho EcuM_Externals.h e apresenta o Service ID 0x48 [SWS_EcuM_02926].

Uso e parâmetros da interface:

• Parâmetros de entrada: Como único parâmetro é passado wakeupSource do tipo EcuM_WakeupSourceType, o qual especifica a(s) fonte(s) de wakeup a parar [SWS_EcuM_02926].
• Valor de retorno e entradas/saídas: Não existem parâmetros de entrada/saída (inout) nem parâmetros de saída (out) [SWS_EcuM_02926]. A função não devolve nenhum valor de retorno (void) ao chamador [SWS_EcuM_02926].
• Comportamento de execução: O processamento da função está definido como síncrono (Synchronous) [SWS_EcuM_02926].

Concorrência e tratamento de erros:

A interface está especificada como não reentrante (Non Reentrant) [SWS_EcuM_02926]. Chamadas paralelas não são, portanto, permitidas e devem ser evitadas pelo chamador. A especificação não define para este callout códigos de erro específicos, valores de retorno ou notificações para o módulo Default Error Tracer (DET) ou Diagnostic Event Manager (DEM) [SWS_EcuM_02926]. Interpretação: Como a função é disponibilizada como callout externo através de EcuM_Externals.h, a desativação relacionada ao hardware do hardware de wakeup em questão, bem como o tratamento interno de erros, incumbem à implementação específica do usuário. Pergunta Q-b537c805bed751ab (aberta)

Utilização e contexto de chamada

A função EcuM_MainFunction possui a assinatura void EcuM_MainFunction(void) com o Service-ID 0x18 e é disponibilizada através do arquivo de cabeçalho SchM_EcuM.h [SWS_EcuM_02837]. Ela não recebe parâmetros e não retorna nenhum valor de retorno [SWS_EcuM_02837]. Sua tarefa consiste em processar todas as atividades do ECU State Manager enquanto o sistema operacional está em execução («OS is up and running») [SWS_EcuM_02837]. A função deve tipicamente ser chamada periodicamente pelo scheduler (interpretação: integração através de SchM_EcuM.h). Pergunta Q-ca471f22bdb1f11d (aberta)

Interação e tarefas

Em operação contínua, EcuM_MainFunction assume tarefas centrais de coordenação:

• Validação de fontes de wakeup: caso haja uma lista de candidatos a fontes de wakeup após a conclusão da sequência WakeupRestart, o módulo EcuM valida esses candidatos dentro de EcuM_MainFunction [SWS_EcuM_02539].
• Expiração do timeout de validação: se o timeout de validação para um evento de wakeup pendente expirar, a função define por meio de uma operação OU o bit correspondente na variável interna para eventos de wakeup expirados [SWS_EcuM_04081]. Além disso, ela notifica o gerenciamento do BSW através de BswM_EcuM_Current_Wakeup com uma máscara de bits EcuM_WakeupSourceType do evento e o status ECUM_WKSTATUS_EXPIRED [SWS_EcuM_04082].
• Alarm Clock Service: se o serviço estiver presente via EcuMAlarmClockPresent, a EcuM_MainFunction atualiza o Alarm Clock Timer [SWS_EcuM_04002].

Restrições e instâncias

Como condição de contorno essencial para arquiteturas multinúcleo ou multi-instância, aplica-se que EcuM_MainFunction deve ser executada em todas as instâncias do EcuM [SWS_EcuM_04011].

O tipo de dados EcuM_RunStatusType está definido como uint8 e é disponibilizado por meio do cabeçalho EcuM.h ([SWS_EcuM_04120]). Ele serve para a representação formal do status atual do protocolo Run-Request no ECU-Manager e é transmitido como resultado ao Basic Software Mode Manager (BswM) ([SWS_EcuM_04120]).

A faixa de valores permitida compreende três estados discretos ([SWS_EcuM_04120]):

• ECUM_RUNSTATUS_UNKNOWN (valor 0): Representa um status desconhecido e serve simultaneamente como valor de inicialização definido (Init Value).
• ECUM_RUNSTATUS_REQUESTED (valor 1): Identifica o estado em que o status RUN foi ativamente solicitado pelo ECU-Manager.
• ECUM_RUNSTATUS_RELEASED (valor 2): Sinaliza que o status RUN foi liberado novamente pelo ECU-Manager.

No que diz respeito à interação, o requisito [SWS_EcuM_04121] obriga o módulo ECU-Manager a informar o BswM de forma vinculativa sobre o estado atual do protocolo Run-Request com base nos valores de status listados em EcuM_RunStatusType. Interpretação: Como o requisito não menciona nenhuma assinatura de função específica ou convenção de chamada para o fluxo de mensagens, a informação de status provavelmente deve ser passada ao módulo BswM por meio de uma função de notificação interna ou interface de callback. Pergunta Q-e136b90c2edbc29c (aberta) Códigos de erro específicos, mensagens DET ou DEM, bem como condições especiais de reentrância não estão previstos para este tipo de dados elementar nos requisitos presentes.

O tipo de dados EcuM_WakeupStatusType descreve, de acordo com [SWS_EcuM_04041], os estados possíveis de uma fonte de wakeup (Wakeup Source) no ECU State Manager. O tipo é derivado do tipo base uint8 e é fornecido através do cabeçalho EcuM.h [SWS_EcuM_04041].

O domínio de valores representa o ciclo de vida de um evento de wakeup ao longo de quatro estados [SWS_EcuM_04041]:

• ECUM_WKSTATUS_NONE (valor 0): Nenhum evento de wakeup pendente foi detectado [SWS_EcuM_04041].
• ECUM_WKSTATUS_PENDING (valor 1): Um evento de wakeup foi detectado, mas ainda não foi validado [SWS_EcuM_04041].
• ECUM_WKSTATUS_VALIDATED (valor 2): O evento de wakeup é válido e foi confirmado com sucesso [SWS_EcuM_04041].
• ECUM_WKSTATUS_EXPIRED (valor 3): O evento de wakeup não foi validado a tempo e, consequentemente, expirou [SWS_EcuM_04041].

Uso e interação: O tipo serve como representação central de status para fontes de wakeup. Interpretação: Os chamadores devem avaliar este status no âmbito de consultas de status para determinar se uma fonte de wakeup está sendo ativamente validada, se já sinalizou um despertar válido ou se a janela temporal de validação foi ultrapassada. Pergunta Q-a3f721e8f1753eb1 (aberta)

O tipo EcuM_StateType é um tipo de dados derivado de uint8, fornecido por meio do cabeçalho EcuM.h e que mapeia os estados operacionais do ECU State Manager [SWS_EcuM_91005]. O módulo EcuM é obrigado a definir todos os estados listados em EcuM_StateType [SWS_EcuM_02664]. A faixa de valores abrange a máscara de subestados ECUM_SUBSTATE_MASK (0x0f), bem como os estados principais ECUM_STATE_STARTUP (0x10), ECUM_STATE_RUN (0x32), ECUM_STATE_POST_RUN (0x33), ECUM_STATE_SHUTDOWN (0x40) e ECUM_STATE_SLEEP (0x50) [SWS_EcuM_91005].

Utilização e interação

O tipo de dados funciona como parâmetro central para a comunicação de estados entre o BswM e o EcuM:

• Mudança de estado para o EcuM: por meio da chamada de função síncrona e reentrante EcuM_SetState(EcuM_StateType state) com o service ID 0x2b, o BswM notifica o módulo EcuM sobre uma mudança de estado [SWS_EcuM_04122].
• Sinalização de estado para o BswM: o EcuM reporta o estado atual ao BswM por meio da chamada da interface BswM_EcuM_CurrentState(EcuM_StateType State) [SWS_EcuM_04143].

Concorrência, ordem e tratamento de erros

Em relação à ordem temporal, aplica-se o requisito de que um novo estado só pode ser definido pelo EcuM após a RTE ter fornecido seu feedback por meio da porta de confirmação correspondente [SWS_EcuM_04143]. Códigos de erro específicos, valores de retorno ou mensagens de DET/DEM não estão previstos para este tipo de dados nas fontes disponíveis.

O tipo EcuM_Mode é definido como ModeDeclarationGroup de acordo com [SWS_EcuM_04107] e representa os estados centrais do ECU State Manager. Como modo inicial está definido STARTUP. Além disso, o grupo inclui os modos definidos POST_RUN, RUN, SHUTDOWN bem como SLEEP [SWS_EcuM_04107].

No conjunto do sistema, EcuM_Mode serve como base de tipos para o grupo de modos currentMode dentro da interface de serviço EcuM_CurrentMode [SWS_EcuM_04108]. Através desta interface, o modo atual da ECU pode ser consultado ou sinalizado para outros componentes de software por meio do mecanismo de modos da RTE.

Em relação ao contexto de chamada e à concorrência, a especificação do próprio tipo não contém restrições explícitas quanto a reentrância ou códigos de erro; o gerenciamento das transições de estado ocorre por meio das interfaces de serviço correspondentes do EcuM.

O elemento currentMode está definido como Provided-Port do módulo EcuM e disponibiliza a interface de serviço EcuM_CurrentMode para a arquitetura de software [SWS_EcuM_04112]. Essa interface de serviço serve para ler o modo atual da ECU e encapsula o grupo de modos currentMode com base no tipo de dados EcuM_Mode [SWS_EcuM_04108].

Durante a operação contínua do sistema, a utilização ocorre para a sinalização de mudanças de estado:

• Chamada e uso: Assim que ocorre uma mudança de modo, o EcuM a reporta a componentes de software (SW-Cs) por meio de portas de modo da RTE [SWS_EcuM_04133]. Sob a premissa de especificação do nome de porta currentMode e com o uso da API direta da RTE, a função Rte_Switch_currentMode_currentMode( Rte_ModeType_EcuM_Mode mode) é chamada para essa finalidade [SWS_EcuM_04133].
• Parâmetros e valor de retorno: O parâmetro mode passa o novo modo a ser assumido para a RTE [SWS_EcuM_04133]. O valor de retorno do tipo Rte_StatusType fornecido pela Switch-API não é avaliado, devendo obrigatoriamente ser ignorado de acordo com a especificação [SWS_EcuM_04133].
• Interação: Um componente de software que deve ser informado sobre mudanças de modo precisa requisitar a interface Mode-Switch EcuM_CurrentMode como Required-Port [SWS_EcuM_04133].

Utilização e gama de valores

O tipo de dados EcuM_ShutdownModeType baseia-se em uint16 e é disponibilizado através do arquivo de cabeçalho Rte_EcuM_Type.h [SWS_EcuM_04101]. Ele mapeia os modos configurados no ECU State Manager. Sua faixa de valores abrange:

• os modos de sleep configurados de acordo com EcuMSleepModeId [SWS_EcuM_04101], bem como
• os modos de reset configurados, calculados a partir do deslocamento 256 + EcuMResetModeId [SWS_EcuM_04101].

Interação e contexto de chamada

O tipo é utilizado em serviços síncronos e reentrantes do ECU Manager:

• EcuM_SelectShutdownTarget recebe shutdownMode como parâmetro de entrada para definir o modo de sleep concreto (no objetivo ECUM_SHUTDOWN_TARGET_SLEEP) ou o mecanismo de reset (no objetivo ECUM_SHUTDOWN_TARGET_RESET) [SWS_EcuM_02822].
• EcuM_GetShutdownTarget retorna, através de um parâmetro de ponteiro para EcuM_ShutdownModeType, qual modo de sleep ou reset configurado está selecionado para o objetivo de shutdown atual [SWS_EcuM_02824].
• EcuM_GetLastShutdownTarget emite o modo de shutdown do procedimento de shutdown precedente através de um parâmetro de saída [SWS_EcuM_02825]. Por meio da interface de serviço EcuM_ShutdownTarget, essa funcionalidade também está disponível para componentes de software (SW-Cs) [SWS_EcuM_03011].

Tratamento de erros e condições de contorno

As funções retornam Std_ReturnType. Se, por exemplo, um ponteiro NULL for passado para EcuM_GetShutdownTarget ou EcuM_GetLastShutdownTarget, a chamada falha com E_NOT_OK [SWS_EcuM_02824], [SWS_EcuM_02825]. Em caso de execução bem-sucedida, os serviços reportam E_OK [SWS_EcuM_02822], [SWS_EcuM_03011].