AUTOSAR Classic Runtime Environment (RTE)

O cluster de módulos Runtime Environment (RTE) realiza o Virtual Functional Bus da AUTOSAR na unidade de controle e disponibiliza APIs padronizadas para a comunicação tipada remetente-destinatário e cliente-servidor de componentes de software [SWS_Rte_01091], [SWS_Rte_01102]. Ele integra o Basic Software Scheduler (SchM) para o escalonamento cíclico dos módulos de software básico e se conecta ao OS/IOC, bem como à pilha de comunicação (COM, LdCom) [SWS_Rte_01376], [SWS_Rte_04546]. Ao mesmo tempo, a RTE garante a consistência de dados e transições de modo determinísticas por meio de áreas protegidas configuráveis, bufferização e fluxos definidos de transição em 10 etapas [SWS_Rte_02665], [SWS_Rte_03504].

mais ›

O cluster de módulos Runtime Environment (RTE) constitui a realização do Virtual Functional Bus (VFB) no nível da unidade de controle. Ele desacopla completamente os componentes de software (SWCs) AUTOSAR do software básico subjacente e coordena o escalonamento de módulos BSW por meio do Basic Software Scheduler (SchM) [SWS_Rte_04546], [SWS_Rte_05165]. O cluster processa tanto acessos internos à partição quanto fluxos de dados entre partições através do OS-IOC, além do barramento da unidade de controle através dos módulos COM e LdCom [SWS_Rte_01376], [SWS_Rte_02736], SWS_RTE p. 106.

Diagrama de contexto: Integração do cluster RTE e SchM entre a camada de aplicação (SWCs), OS/IOC e serviços de software básico. Fontes: [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE p. 106.

A comunicação baseia-se em padrões remetente-destinatário e cliente-servidor: dados S/R são transmitidos implicitamente consistentes por meio de cópias de buffer (`Rte_IRead`/`Rte_IWrite`) ou explicitamente diretos e bufferizados (`Rte_Read`/`Rte_Write`/`Rte_Receive`) [SWS_Rte_01091], [SWS_Rte_02521], [SWS_Rte_06000]. Em caso de falha ou presença de sinais inválidos, entram em ação mecanismos como substituição por `initValue` ou estratégias `handleInvalid` [SWS_Rte_05030], [SWS_Rte_06009]. Chamadas cliente-servidor (`Rte_Call`, `Rte_Result`) em execução assíncrona são sincronizadas através de filas FIFO no lado do servidor e do cliente e associadas de forma inequívoca por meio de identificadores de transação (transaction handles) [SWS_Rte_01102], [SWS_Rte_02527], [SWS_Rte_02649].

No gerenciamento de tarefas e ciclo de vida, a RTE assegura a reentrância por meio de compartilhamento de código e protege seções críticas por mecanismos de bloqueio configuráveis, como bloqueios de interrupção, recursos de OS ou spinlocks de OS [SWS_Rte_03015], [SWS_Rte_03504]. Mudanças de modo passam por uma sequência estrita de 10 etapas, desde ativações OnExit, OnTransition até OnEntry, e são concluídas de maneira ordenada por meio de eventos de confirmação [SWS_Rte_02665], [SWS_Rte_02679].

mais ›

Arquitetura do sistema & papel do cluster de módulos

O cluster de módulos da Runtime Environment (RTE) constitui a espinha dorsal funcional e de comunicação da AUTOSAR Classic Platform. Ele representa a realização concreta do Virtual Functional Bus (VFB) em uma unidade de controle e desacopla completamente os componentes de software (SWCs) do Basic Software (BSW) subjacente, bem como do hardware do microcontrolador SWS_RTE p. 106. Dentro do cluster, a RTE propriamente dita assume a intermediação da comunicação inter e intra-ECU relacionada à aplicação, enquanto o Basic Software Scheduler (SchM) integrado controla o controle de fluxo, a garantia de consistência e o escalonamento cíclico dos módulos BSW [SWS_Rte_04546], [SWS_Rte_05165].

A arquitetura estabelece interfaces padronizadas entre SWCs de aplicação, componentes de sensor/atuador e as camadas de BSW. Para a interconexão em nível de veículo, o cluster RTE baseia-se diretamente na pilha de comunicação: mensagens orientadas a sinais são transferidas para o módulo COM, enquanto grandes volumes de dados são processados através do módulo LdCom (Large Data COM) [SWS_Rte_01376], [SWS_Rte_04527]. O isolamento de processos e memória além dos limites de partições e núcleos é fornecido pelo sistema operacional (OS) AUTOSAR e pelo seu mecanismo de Inter-OS-Application-Communication (IOC) [SWS_Rte_02736]. Dados de calibração e blocos de memória conectam-se por meio de descritores padronizados ao NVRAM Manager (NvM) e a ferramentas de calibração [SWS_Rte_03961], [SWS_Rte_05118].

Diagrama de contexto: Integração do cluster RTE e SchM entre a camada de aplicação (SWCs), OS/IOC e serviços de software básico. Fontes: [SWS_Rte_05165], [SWS_Rte_02736], [SWS_Rte_01376], SWS_RTE p. 106.

Interação e caminhos de interação entre os módulos

A interação no cluster RTE diferencia rigorosamente entre comunicação remetente-destinatário (S/R) e cliente-servidor (C/S). Na comunicação S/R, a RTE suporta tanto semânticas de leitura e escrita implícitas quanto explícitas: no acesso implícito (`Rte_IRead`, `Rte_IWrite`), a RTE cria uma cópia local no início da execução da runnable, a qual é mantida consistente durante todo o tempo de execução [SWS_Rte_06000], [SWS_Rte_03744]. No acesso explícito (`Rte_Read`, `Rte_Write`, `Rte_Send`, `Rte_Receive`), a troca de dados ocorre de forma diretamente síncrona ou por meio de filas [SWS_Rte_01091], [SWS_Rte_01092]. Para eventos com filas (`swImplPolicy = queued`), a RTE configura filas FIFO no lado receptor; se tal buffer estourar, o elemento é descartado e um estado de erro é definido [SWS_Rte_02521], [SWS_Rte_02523].

Caso o caminho de dados atravesse limites de unidades de controle (inter-ECU), a RTE transforma e serializa estruturas de dados compostas e chama `Com_SendSignal` ou `Com_SendSignalGroup` para garantir a transmissão atômica de PDU no módulo COM [SWS_Rte_04527]. Para grandes arrays de dados, a RTE recorre alternativamente ao `LdCom_Transmit` e, no caso de protocolos de transporte (TP), bloqueia o buffer correspondente até a confirmação por meio de callbacks [SWS_Rte_01377], [SWS_Rte_01379]. No lado receptor, a RTE recebe dados de forma assíncrona através de callbacks de COM e deriva deles eventos de ativação para runnables de aplicação [SWS_Rte_03530], [SWS_Rte_03531]. Caso nenhum dado de barramento tenha chegado ainda, a RTE fornece valores iniciais configurados [SWS_Rte_06009], [SWS_Rte_06010].

Diagrama de sequência: Fluxo explícito de dados remetente-destinatário através de limites de unidades de controle com bufferização e emissão de valores iniciais. Fontes: [SWS_Rte_06010], [SWS_Rte_04527], [SWS_Rte_03530], AUTOSAR_SWS_RTE p. 148.

Na comunicação cliente-servidor, a RTE gera `Rte_Call` para chamadas síncronas e APIs de chamada e consulta separadas (`Rte_Call`, `Rte_Result`) para chamadas assíncronas [SWS_Rte_01102], [SWS_Rte_01111]. Caso as chamadas não possam ser resolvidas diretamente como função C no mesmo contexto, a RTE armazena em buffer as requisições no nível do servidor em filas FIFO e as respostas no nível do cliente em uma fila de profundidade 1 [SWS_Rte_02527], [SWS_Rte_02528]. Para chamadas C/S entre partições ou entre unidades de controle, a RTE utiliza identificadores de transação (transaction handles) compostos por ID de cliente e contador de sequência para atribuir precisamente as respostas ao chamador original [SWS_Rte_02649], [SWS_Rte_03885].

Sincronização, reentrância e contextos de tarefas

A execução de código de programa no cluster RTE ocorre dentro de tarefas de OS ou contextos de ISR. A RTE diferencia entre runnables simples (categoria 1 sem chamadas de OS bloqueantes) e runnables estendidas (categoria 2 com pontos de espera), que são despertadas do estado `WaitPoint` por eventos como `DataReceivedEvent` ou callbacks de COM [SWS_Rte_03532], SWS_RTE p. 304. A ativação concorrente da mesma instância de uma Runnable Entity é estritamente proibida, a menos que o atributo `canBeInvokedConcurrently` esteja explicitamente definido como `TRUE` [SWS_Rte_03523]. No caso de SWCs multi-instanciados, a AUTOSAR adota consistentemente o compartilhamento de código: múltiplas instâncias compartilham o mesmo código executável, mas acessam dados separados e Per-Instance-Memory (PIM) por meio de descritores específicos da instância [SWS_Rte_02002], [SWS_Rte_03015], [SWS_Rte_02301].

Para a proteção de seções críticas, a RTE gera as chamadas Exclusive Areas (`Rte_Enter`, `Rte_Exit`). O mecanismo de sincronização subjacente é configurado por meio do parâmetro `RteExclusiveAreaImplMechanism` [SWS_Rte_03504]. Para isso, estão disponíveis cinco estratégias definidas:

• ALL_INTERRUPT_BLOCKING: Bloqueio global de todas as interrupções de hardware [SWS_Rte_03504].
• OS_INTERRUPT_BLOCKING: Bloqueio seletivo de interrupções específicas de OS (categoria 2) [SWS_Rte_03504].
• OS_RESOURCE: Utilização de recursos do sistema operacional OSEK/AUTOSAR com Priority Ceiling Protocol [SWS_Rte_03504].
• OS_SPINLOCK: Sincronização compatível com multinúcleo via spinlocks de OS para a coordenação entre tarefas e ISRs de diferentes núcleos [SWS_Rte_03504].
• NONE: Dispensa de bloqueios internos, desde que a consistência dos dados já esteja assegurada por priorização estrita de tarefas ou escalonamento [SWS_Rte_03504].

Se dados forem transferidos entre diferentes partições de proteção de memória, a RTE verifica parâmetros de ponteiro para impedir acessos não autorizados à memória a partir de partições não confiáveis [SWS_Rte_02752], [SWS_Rte_02753].

Ciclos de vida típicos e modos de operação

O ciclo de vida do sistema está sujeito a uma estrita divisão de fases entre inicialização, operação regular e desligamento controlado. Na inicialização do sistema, a parte do SchM é inicializada primeiro: o EcuM chama `SchM_Start` em cada núcleo de processador antes que módulos BSW como o BswM sejam iniciados [SWS_Rte_04546], [SWS_Rte_04548]. Em seguida, `SchM_StartTiming` ativa os eventos periódicos de BSW e as MainFunctions [SWS_Rte_04549], [SWS_Rte_04551]. De acordo com a restrição de design, `SchM_Start` e `SchM_StartTiming` devem ser chamados exatamente uma vez por núcleo SWS_RTE p. 928. Depois disso, `Rte_Start` habilita a RTE de aplicação; se a alocação de recursos internos falhar, a inicialização é abortada com `RTE_E_LIMIT` [SWS_Rte_01261], [SWS_Rte_01262].

Modos de operação são mapeados por meio de Mode-Declaration-Groups. Quando um Mode Manager dispara uma mudança de modo através de `Rte_Switch`, ela é enfileirada em uma fila FIFO [SWS_Rte_02631], [SWS_Rte_02718], [SWS_Rte_02719]. Cada máquina de modo passa por uma sequência obrigatória de 10 etapas durante a comutação [SWS_Rte_02665]: primeiro, as desativações de modo para o modo de destino tornam-se efetivas e aguarda-se o término de entidades em execução (etapas 1–2). Segue-se a execução sequencial e o término de Executable Entities OnExit (etapas 3–4), OnTransition (etapas 5–6) e OnEntry (etapas 7–8). Por fim, a desativação do modo anterior é revogada e o novo modo é ativado (etapa 9), antes que a mudança de modo seja confirmada via `ModeSwitchedAckEvent` ou `Rte_SwitchAck` (etapa 10) [SWS_Rte_02665], [SWS_Rte_02679], [SWS_Rte_02725]. Por meio de `RteModeToScheduleTableMapping`, os modos de operação também podem ser vinculados diretamente a tabelas de escalonamento (Schedule Tables) do OS [SWS_Rte_05146].

Diagrama de sequência: Fluxo padronizado de 10 etapas de uma mudança de modo AUTOSAR com confirmação. Fontes: [SWS_Rte_02665], [SWS_Rte_02679], EXP_ModeManagementGuide p. 16.

A desinicialização ocorre no início da fase de shutdown por meio de `Rte_Stop`. Após essa chamada, a RTE bloqueia a ativação, inicialização ou liberação de outras runnables no respectivo núcleo [SWS_Rte_02538]. Dados S/R e requisições C/S recebidos no estado parado da RTE são descartados e ignorados [SWS_Rte_02535], [SWS_Rte_02536].

Tratamento de erros, monitoramento de status e validação de dados

Estados de erro e status de interface são transmitidos uniformemente ao chamador na RTE por meio do tipo escalar `Std_ReturnType` [SWS_Rte_01034], SWS_RTE p. 586. A RTE diferencia entre erros de aplicação (valores de erro 1–63), erros imediatos de infraestrutura (valores 128–255), bem como bits de status sobrepostos, como perda de dados (`RTE_E_LOST_DATA = 64`) ou expiração/desatualização (`RTE_E_MAX_AGE_EXCEEDED = 64`) SWS_RTE p. 586. Valores de retorno típicos de infraestrutura incluem comunicação parada (`RTE_E_COM_STOPPED = 128`), timeouts de comunicação e resposta (`RTE_E_TIMEOUT = 129`), ausência de dados (`RTE_E_NO_DATA = 131`) e estouro de recursos (`RTE_E_LIMIT = 130`) [SWS_Rte_01060], [SWS_Rte_01061], [SWS_Rte_01064]. Com a verificação de intervalo de valores ativa, a RTE sinaliza violações de intervalo com `RTE_E_OUT_OF_RANGE` [SWS_Rte_03845], [SWS_Rte_03846].

Para o tratamento de sinais não plausíveis ou com erro, a RTE fornece mecanismos para invalidação de dados. No lado emissor, `Rte_Invalidate` marca o sinal com um valor de substituição definido [SWS_Rte_01206], [SWS_Rte_05024]. No lado receptor, o atributo `handleInvalid` controla a estratégia de substituição: em `keep`, o valor anterior é mantido e um `DataReceiveErrorEvent` é disparado, enquanto em `replace` ocorre uma substituição automática pelo `initValue` [SWS_Rte_05030], [SWS_Rte_05049]. Falhas de comunicação no nível da rede são monitoradas via `aliveTimeout`; se o tempo de monitoramento expirar, o módulo COM relata à RTE um timeout de recepção via `Rte_COMCbkRxTOut`, após o que os componentes dependentes são informados ou valores de fallback são ativados [SWS_Rte_08061].