AUTOSAR Classic Operating System

O cluster de módulos Operating System fornece o escalonamento determinístico em tempo real para tarefas e ISRs, bem como proteção de memória e encapsulamento de falhas em OS-Applications particionadas [SWS_Os_00445]. Ele suporta sistemas multinúcleo por meio de spinlocks inter-núcleos, ativação assíncrona de tarefas e o Inter-OS-Application Communicator (IOC) [SWS_Os_00686], [SWS_Os_00824]. Na ocorrência de violações de proteção, o OS permite, por meio de hooks configuráveis, o encerramento direcionado ou o reinício controlado de partições individuais em tempo de execução ApplicationLevelErrorHandling p. 53.

mais ›

O cluster de módulos “Operating System” fornece, no AUTOSAR Classic, a infraestrutura fundamental de execução e proteção para componentes de software e módulos de software básico. O sistema operacional encapsula recursos como tarefas, ISRs, alarmes e contadores em OS-Applications [SWS_Os_00445], diferenciando entre partições confiáveis (trusted) e não confiáveis [SWS_Os_00446], a fim de garantir contenção estrita de falhas com base na proteção de memória por MPU SafetyConceptStatusReport p. 49. Em sistemas multinúcleo, o OS gerencia núcleos lógicos por meio de IDs de núcleo padronizados [SWS_Os_00790] e fornece o Inter-OS-Application Communicator (IOC) para a troca baseada em dados e eventos entre núcleos e partições [SWS_Os_00824].

Diagrama de contexto: integração do cluster de OS na arquitetura de software básico do AUTOSAR e interfaces para EcuM, StbM, RTE e hardware. Fontes: [SWS_Os_00445], [SWS_Os_00790], SWS_BSWGeneral p. 48.

Além do escalonamento de tarefas orientado a eventos, o OS permite o controle de execução baseado em tempo por meio de Schedule Tables [SWS_Os_00783]. Estas podem ser ajustadas a bases de tempo globais do veículo via Synchronized Time-Base Manager (StbM) por meio de SyncScheduleTable [SWS_Os_00199], SWS_SynchronizedTimeBaseManager p. 220. Para a sincronização entre limites de núcleos, o módulo oferece spinlocks de baixo nível com detecção integrada de deadlocks [SWS_Os_00686], enquanto ativações de tarefas inter-núcleos podem ser executadas de forma assíncrona com ActivateTaskAsyn [SWS_Os_91022].

Em caso de falha (como em estouros de memória), o OS ativa o ProtectionHook [SWS_Os_00538]. Por meio do seu valor de retorno, uma OS-Application com falha pode ser isolada e finalizada de forma controlada ou reinicializada por meio de uma tarefa de reinício dedicada, sem reiniciar todo o sistema [SWS_Os_00787], ApplicationLevelErrorHandling p. 53.

Diagrama de estados: ciclo de vida e estados de particionamento de uma OS-Application do AUTOSAR em caso de falha. Fontes: [SWS_Os_00773], [SWS_Os_00258], ApplicationLevelErrorHandling p. 53.

mais ›

1. Arquitetura de sistema & papel do cluster de módulos

O cluster de módulos “Operating System” constitui, no modelo de camadas do AUTOSAR, a base fundamental dos System Services para a execução e coordenação de todos os componentes de software de tempo real e módulos de software básico. O módulo central [SWS_Os_00445] encapsula tarefas, rotinas de serviço de interrupção (ISRs), alarmes, contadores (Counter) e tabelas de execução (Schedule Tables) em unidades de execução configuráveis, as chamadas OS-Applications. O sistema operacional diferencia estritamente entre OS-Applications confiáveis (trusted) e não confiáveis (non-trusted) [SWS_Os_00446], a fim de fornecer segurança funcional e proteção de memória de acordo com as classes de escalabilidade exigidas SafetyConceptStatusReport p. 49.

Em arquiteturas multinúcleo, o OS gerencia núcleos lógicos que são referenciados por meio de identificadores unívocos do tipo CoreIdType [SWS_Os_00790]. Os IDs de núcleo são baseados em zero e dispostos consecutivamente [SWS_Os_00825], sendo que a constante OS_CORE_ID_MASTER identifica o núcleo mestre SWS_OS p. 111. Por meio do Inter-OS-Application Communicator (IOC) integrado, o sistema operacional fornece mecanismos para a transferência de dados segura, entre partições e entre núcleos [SWS_Os_00824]. Graças à padronização das interfaces de acordo com o OSEK OS e suas extensões específicas do AUTOSAR, o OS garante comportamento determinístico em tempo real para módulos de nível superior, como o ECU State Manager (EcuM), o Synchronized Time-Base Manager (StbM) e o ambiente de tempo de execução RTE SWS_BSWGeneral p. 48.

Diagrama de contexto: integração do cluster de OS na arquitetura de software básico do AUTOSAR e interfaces para EcuM, StbM, RTE e hardware. Fontes: [SWS_Os_00445], [SWS_Os_00790], SWS_BSWGeneral p. 48.

2. Interação & caminhos de interação entre os módulos

A interação entre os objetos de OS e as camadas da arquitetura AUTOSAR ocorre por meio de caminhos de controle e de dados claramente delimitados. Para a troca de dados entre partições, o IOC gera funções de comunicação tipadas com semântica unqueued (“data”, IocWrite / IocRead) ou queued (“event”, IocSend / IocReceive) [SWS_Os_00718], [SWS_Os_00738]. Em transmissões em grupo, são empregados os serviços IocSendGroup e IocReceiveGroup, respectivamente [SWS_Os_00728], [SWS_Os_00746]. Se um buffer interno do receptor ficar cheio, o IOC sinaliza isso com o status IOC_E_LIMIT para o emissor e registra um IOC_E_LOST_DATA para operações de leitura subsequentes SWS_OS p. 225.

Quando uma OS-Application não confiável precisa acessar serviços privilegiados de uma partição confiável, a mudança controlada de contexto ocorre por meio do serviço de sistema CallTrustedFunction [SWS_Os_00097]. Nesse processo, os parâmetros são passados por meio de uma estrutura de ponteiro do tipo TrustedFunctionParameterRefType [SWS_Os_00776]. O sistema operacional altera temporariamente as permissões de MPU para as da aplicação de destino SWS_OS p. 172. A função GetCurrentApplicationID retorna, durante essa execução, o identificador da Trusted Application chamada, ao passo que GetApplicationID fornece a aplicação chamadora original [SWS_Os_00797].

Para o alinhamento temporal com bases de tempo externas, o módulo StbM sincroniza Schedule Tables configuradas explicitamente por meio das interfaces do OS. O StbM consulta primeiro ciclicamente o estado de sincronização via GetScheduleTableStatus [SWS_Os_00227] e, em seguida, transmite o valor atual de sincronização ao OS mediante SyncScheduleTable [SWS_Os_00199]. O sistema operacional calcula então o desvio em relação aos pontos de expiração (Expiry Points) e ajusta os tempos de atraso progressivamente, até que a tabela funcione de forma síncrona com a base de tempo global SWS_OS p. 57, SWS_SynchronizedTimeBaseManager p. 220.

Diagrama de sequência: sincronização explícita de uma OS-Schedule-Table pelo Synchronized Time-Base Manager (StbM). Fontes: [SWS_Os_00199], [SWS_Os_00227], SWS_SynchronizedTimeBaseManager p. 220.

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

O modelo de tempo de execução distingue claramente entre o nível de tarefa, os níveis de interrupção da categoria 1 (Cat 1 ISR) e da categoria 2 (Cat 2 ISR), bem como rotinas de gancho (hook routines). Enquanto as Cat 1 ISRs são executadas sem overhead do sistema operacional e não podem chamar serviços do OS, as Cat 2 ISRs são totalmente gerenciadas pelo OS [SWS_Os_00782]. O identificador da ISR ativa pode ser determinado mediante GetISRID; em caso de chamada fora de uma Cat 2 ISR, o serviço retorna INVALID_ISR [SWS_Os_00511]. Fontes de interrupção individuais podem ser controladas de forma direcionada no nível do controlador de interrupções por meio de EnableInterruptSource, DisableInterruptSource e ClearPendingInterrupt [SWS_Os_91020], [SWS_Os_91019], [SWS_Os_91021].

Para a sincronização de seções críticas através dos limites dos núcleos de processamento, o OS disponibiliza spinlocks [SWS_Os_00791]. Um spinlock é ocupado de forma síncrona bloqueante com GetSpinlock [SWS_Os_00686] ou consultado de modo não bloqueante via TryToGetSpinlock [SWS_Os_00703]. A liberação ocorre por meio de ReleaseSpinlock [SWS_Os_00695]. Para excluir deadlocks, o OS verifica no estado estendido a existência de erros de aninhamento e sobreposição (E_OS_INTERFERENCE_DEADLOCK, E_OS_NESTING_DEADLOCK) SWS_OS p. 199.

Para ativações de tarefas e definição de eventos entre núcleos, o OS disponibiliza variantes de API assíncronas: ActivateTaskAsyn e SetEventAsyn retornam imediatamente ao chamador, sem aguardar a execução no núcleo de destino [SWS_Os_91022], [SWS_Os_91023]. Possíveis erros não são retornados ao chamador, mas registrados por meio de error hooks configurados [SWS_Os_00816], SWS_OS p. 203.

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

A inicialização do sistema é coordenada principalmente pelo ECU State Manager (EcuM). No núcleo mestre, o EcuM inicia núcleos subordinados antes da inicialização do sistema operacional por meio do serviço do OS StartCore [SWS_Os_00676], SWS_ECUStateManager p. 82. Em seguida, cada núcleo iniciado chama StartOS de forma autônoma. Após a chamada de StartOS, o sistema operacional comuta todas as OS-Applications configuradas para o estado APPLICATION_ACCESSIBLE, antes que os startup hooks sejam executados SWS_OS p. 62. O número de núcleos inicializados com sucesso pode ser consultado em tempo de execução com GetNumberOfActivatedCores SWS_OS p. 196.

As Schedule Tables estão sujeitas a uma máquina de estados claramente definida. Elas podem ser iniciadas de modo absoluto via StartScheduleTableAbs [SWS_Os_00358], relativo via StartScheduleTableRel [SWS_Os_00347] ou síncrono via StartScheduleTableSynchron [SWS_Os_00201]. As tabelas podem ser encadeadas (NextScheduleTable, estado SCHEDULETABLE_NEXT) [SWS_Os_00191] ou transferidas imediatamente para o estado inativo SCHEDULETABLE_STOPPED com StopScheduleTable [SWS_Os_00006]. Uma sincronização explícita em andamento pode ser cancelada mediante SetScheduleTableAsync, sendo que o processamento dos Expiry Points continua [SWS_Os_00422].

Para modos de economia de energia em marcha lenta, o OS oferece a interface ControlIdle, com a qual o EcuM pode configurar o estado de repouso de núcleos individuais [SWS_Os_00769]. Durante o desligamento, o EcuM coordena a desinicialização de todas as camadas e finalmente chama ShutdownAllCores ou ShutdownOS para parar o sistema global de forma controlada SWS_ECUStateManager p. 90.

5. Tratamento de erros, rastreamento de DET e degradação

Violações de proteção (como estouros de memória ou violações de temporização) levam à ativação do ProtectionHook global [SWS_Os_00538]. Com base no erro, o hook decide a estratégia de recuperação por meio de um valor de retorno do tipo ProtectionReturnType [SWS_Os_00787]: término da entidade causadora (PRO_TERMINATETASKISR), término completo da partição afetada (PRO_TERMINATEAPPL), inicialização de um reinício controlado da partição (PRO_TERMINATEAPPL_RESTART) ou desligamento da ECU (PRO_SHUTDOWN) ApplicationLevelErrorHandling p. 60.

Se uma OS-Application for encerrada ou reiniciada, o OS a transfere do estado APPLICATION_ACCESSIBLE para APPLICATION_RESTARTING ou APPLICATION_TERMINATED [SWS_Os_00773]. Todas as tarefas ativas, ISRs, alarmes e Schedule Tables da partição são interrompidos imediatamente e todas as interrupções são desativadas [SWS_Os_00447]. No estado APPLICATION_RESTARTING, executa-se exclusivamente o OsRestartTask para realizar limpezas antes que a operação normal seja liberada novamente ApplicationLevelErrorHandling p. 53, ApplicationLevelErrorHandling p. 76.

Diagrama de estados: ciclo de vida e estados de particionamento de uma OS-Application do AUTOSAR em caso de falha. Fontes: [SWS_Os_00773], [SWS_Os_00258], ApplicationLevelErrorHandling p. 53.

Para a prevenção preventiva de erros, o sistema operacional oferece funções de verificação de proteção de memória como CheckTaskMemoryAccess e CheckISRMemoryAccess [SWS_Os_00512], [SWS_Os_00513], bem como verificações de permissão de acesso via CheckObjectAccess e CheckObjectOwnership [SWS_Os_00256], [SWS_Os_00017]. Por meio dessas verificações padronizadas, pode-se assegurar que componentes não confiáveis não realizem acessos não autorizados de escrita ou de execução na memória SWS_OS p. 73.