AUTOSAR Classic General & Standard Types

O cluster de módulos General & Standard Types disponibiliza, por meio dos cabeçalhos Platform_Types.h, Std_Types.h e ComStack_Types.h, a base independente de hardware para todos os tipos de dados, retornos de status e buffers de comunicação da Classic Platform (AUTOSAR_SRS_BSWGeneral p. 62). Ele padroniza características arquiteturais fundamentais, como modelos de endianness, valores de retorno padronizados como Std_ReturnType e estruturas de comunicação como PduInfoType ([SWS_Std_00005], [SWS_COMTYPE_00008]). Por se tratar de definições puras de cabeçalho sem código executável, o cluster não requer configuração de tempo de execução nem possui tarefas próprias ou tratamento ativo de erros (SWS_StandardTypes p. 27).

mais ›

O cluster de módulos General & Standard Types abrange os três cabeçalhos básicos platform (Platform_Types.h), std (Std_Types.h) e comstack (ComStack_Types.h). Como definições puras de tipos, eles não contêm nenhum código executável e não requerem configuração (SWS_StandardTypes p. 27). Eles formam o fundamento em toda a plataforma para uma tipagem independente de hardware, uniformizam particularidades de compilador e de hardware e fornecem a todos os módulos BSW e à RTE estruturas de dados consistentes (AUTOSAR_SRS_BSWGeneral p. 62).

Diagrama de arquitetura: arquitetura estática de camadas e inclusão do cluster de módulos 'General & Standard Types' com interfaces de tipos exportadas. Fontes: AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

A hierarquia de inclusão constrói-se progressivamente: Platform_Types.h encapsula propriedades específicas da plataforma, como o tipo C99 boolean ([SWS_Platform_00027]), ponteiros de buffer universais como ConstVoidPtr ([SWS_Platform_91002]), bem como símbolos para a ordem dos bits dos registradores CPU_BIT_ORDER ([SWS_Platform_00038]) e a ordem dos bytes de memória CPU_BYTE_ORDER ([SWS_Platform_00039]). Com base nisso, Std_Types.h disponibiliza constantes padrão universais como STD_ON/STD_OFF ([SWS_Std_00010]), estruturas de versão de módulo via Std_VersionInfoType ([SWS_Std_00015]), bem como o sistema de status fundamental Std_ReturnType com E_OK e E_NOT_OK ([SWS_Std_00005], [SWS_Std_00006]).

Para a pilha de comunicação do AUTOSAR, ComStack_Types.h define todos os tipos de interface interprotocolos, como PduIdType ([SWS_COMTYPE_00005]), NetworkHandleType ([SWS_COMTYPE_00038]) e a estrutura central de buffer PduInfoType ([SWS_COMTYPE_00008]). Em protocolos de transporte segmentados (por exemplo, CanTp ou DoIP), o tipo de retorno BufReq_ReturnType controla, juntamente com RetryInfoType, a reserva síncrona de buffer e a cópia de dados entre as camadas BSW (SWS_DiagnosticCommunicationManager p. 291, [SWS_COMTYPE_00012]).

Diagrama de sequência: caminho segmentado de recepção e buffer de um protocolo de transporte utilizando ComStack_Types (PduInfoType, BufReq_ReturnType). Fontes: SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274

Embora o cluster não possua tratamento de erros próprio ou notificações DET (SWS_StandardTypes p. 27), Std_ReturnType estrutura o tratamento de erros de todo o sistema: os bits 0 a 5 (0x00 a 0x3F) são reservados para erros padrão e de aplicação, enquanto os bits 6 e 7 são ocupados exclusivamente pela RTE ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Todas as definições de tipos são especificadas para o uso reentrante em contextos de multitarefa e de interrupção (SWS_CANInterface p. 87).

mais ›

Arquitetura do sistema & papel do cluster de módulos

O cluster de módulos General & Standard Types forma o fundamento tipológico e de abstração de hardware fundamental da AUTOSAR Classic Platform no release R20-11. Ele é composto pelos três módulos puros de cabeçalho platform ([SWS_Platform_00038]), std ([SWS_Std_00005]) e comstack ([SWS_COMTYPE_00005]). De acordo com a arquitetura BSW, esses módulos não disponibilizam código C executável próprio nem requisitam outros drivers BSW (SWS_StandardTypes p. 27). Sua tarefa central consiste em encapsular dependências de compilador e processador, disponibilizar tipos básicos uniformes em toda a plataforma e estabelecer estruturas de dados padronizadas para as camadas de comunicação.

A hierarquia de camadas segue uma ordem estrita e unidirecional de inclusão: o arquivo Platform_Types.h abstrai as propriedades da arquitetura de microcontrolador subjacente (como disposição de registradores e memória, bem como tipos elementares C99), enquanto Std_Types.h baseia-se nele e define valores de retorno universais, bem como constantes de status (AUTOSAR_SRS_BSWGeneral p. 62). Com base nisso, ComStack_Types.h declara todos os tipos de dados interbarramentos e interprotocolos para redes como CAN, FlexRay, LIN e Ethernet, bem como para protocolos de transporte segundo a ISO 15765-2 e protocolos de diagnóstico segundo a ISO 14229 ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). Por meio desse desacoplamento, garante-se que camadas superiores, como o ambiente de execução (RTE) e componentes de software de aplicação (SWCs), permaneçam totalmente portáveis (SWS_RTE p. 818).

Diagrama de arquitetura: arquitetura estática de camadas e inclusão do cluster de módulos 'General & Standard Types' com interfaces de tipos exportadas. Fontes: AUTOSAR_SRS_BSWGeneral p. 62, [SWS_Std_00005], [SWS_COMTYPE_00005]

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

A cooperação dentro do cluster baseia-se em uma cadeia de inclusão estática: ComStack_Types.h inclui Std_Types.h, que, por sua vez, inclui Platform_Types.h (RS_BSWGeneral p. 60). O módulo platform define grandezas fundamentais como boolean, que deve ser obrigatoriamente mapeado para o tipo básico C99 _Bool ([SWS_Platform_00027]), e estabelece sua estrita atribuição de valores por meio dos literais TRUE e FALSE ([SWS_Platform_00034]). Além disso, são especificados ponteiros de buffer genéricos como ConstVoidPtr, que são utilizados para buffers de passagem imutáveis para interfaces de funções chamadas ([SWS_Platform_91002]).

Adicionalmente, platform harmoniza os endiannesses de hardware por meio de símbolos padronizados de pré-processador: para a ordem dos bits em registradores, CPU_BIT_ORDER é definido como MSB_FIRST ou LSB_FIRST ([SWS_Platform_00038], [SWS_Platform_00048], [SWS_Platform_00049]). A ordem dos bytes na memória física é controlada via CPU_BYTE_ORDER, distinguindo-se HIGH_BYTE_FIRST (big-endian, MSB em endereço inferior) de LOW_BYTE_FIRST (little-endian, LSB em endereço inferior) ([SWS_Platform_00039], [SWS_Platform_00050], [SWS_Platform_00051]).

Diagrama estrutural: mapeamento em memória de valores escalares multibyte em big-endian (HIGH_BYTE_FIRST) vs. little-endian (LOW_BYTE_FIRST). Fontes: AUTOSAR_CP_SWS_PlatformTypes p. 16, AUTOSAR_CP_SWS_PlatformTypes p. 15, [SWS_Platform_00050], [SWS_Platform_00051]

No nível seguinte de abstração, o módulo std define símbolos universais para estados de comutação e níveis lógicos: STD_HIGH (0x01u) e STD_LOW (0x00u) para níveis físicos de tensão ([SWS_Std_00007]), STD_ON (0x01u) e STD_OFF (0x00u) para modos de ativação ([SWS_Std_00010]), bem como STD_ACTIVE (0x01u) e STD_IDLE (0x00u) para estados lógicos de execução ([SWS_Std_00013]). Para protocolos de mensagens e transformadores, std disponibiliza adicionalmente Std_MessageTypeType com os literais STD_MESSAGETYPE_REQUEST (0x00) e STD_MESSAGETYPE_RESPONSE (0x01) ([SWS_Std_91001], [SWS_Std_00017]), bem como o tipo de ponteiro de função Std_ExtractProtocolHeaderFieldsType para a extração de cabeçalhos de protocolo ([SWS_Std_91003]).

O módulo comstack, por sua vez, utiliza os tipos básicos de platform e std para estruturar todo o intercâmbio de dados e buffers na pilha de comunicação. A estrutura central de interface é PduInfoType, que agrupa o ponteiro de dados SduDataPtr (uint8*), o ponteiro de metadados MetaDataPtr e o comprimento do buffer SduLength do tipo PduLengthType ([SWS_COMTYPE_00008], [SWS_COMTYPE_00011]). A identificação da I-PDU ocorre via PduIdType ([SWS_COMTYPE_00005]). Para o gerenciamento de canais de comunicação e sub-redes inteiros, comstack define o identificador de canal NetworkHandleType ([SWS_COMTYPE_00038]), bem como o identificador de sub-rede PNCHandleType ([SWS_COMTYPE_00036]), que são empregados, por exemplo, no Synchronized PNC Shutdown do ComM e do Nm (SWS_COMManager p. 171).

Em transmissões segmentadas de protocolos de transporte (TP), a negociação de buffers é processada por meio dos tipos de retorno BufReq_ReturnType e da estrutura RetryInfoType ([SWS_COMTYPE_00012]). Em chamadas síncronas de cópia como CopyTxData ou CopyRxData entre módulos como CanTp, PduR, DCM, DoIP ou SecOC, BUFREQ_OK sinaliza o procedimento de cópia bem-sucedido, enquanto BUFREQ_E_BUSY informa que temporariamente não há buffer suficiente disponível e que uma nova tentativa pode ser realizada (SWS_DiagnosticCommunicationManager p. 291, SWS_SecureOnboardCommunication p. 76). Por meio de RetryInfoType com parâmetros como TP_CONFPENDING ou TP_DATACONF, assegura-se que os dados permaneçam no buffer para eventuais repetições ou sejam liberados após confirmação (SWS_IntrusionDetectionSystemManager p. 49).

Diagrama de sequência: caminho segmentado de recepção e buffer de um protocolo de transporte utilizando ComStack_Types (PduInfoType, BufReq_ReturnType). Fontes: SWS_PDURouter p. 112, SWS_DiagnosticCommunicationManager p. 273, SWS_DiagnosticCommunicationManager p. 274

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

Como os módulos platform, std e comstack são arquivos de cabeçalho puros, sem arquivos-objeto executáveis, eles naturalmente não implementam MainFunctions cíclicos e não possuem contextos de tarefas próprios (SWS_StandardTypes p. 27). No entanto, definem as assinaturas e convenções de tipos para funções que são chamadas através das fronteiras entre camadas. Todas as definições de tipos são concebidas de forma a poderem ser passadas sem restrições de maneira reentrante e sem estado (SWS_CANInterface p. 87).

O uso prático dos tipos ocorre em ambientes altamente assíncronos e concorrentes. Callbacks de recepção de dados como CanIf_RxIndication ou Dcm_CopyRxData, que utilizam PduInfoType e PduIdType, podem ser executados explicitamente em contexto de interrupção (SWS_CANInterface p. 164, SWS_DiagnosticCommunicationManager p. 274). Em contrapartida, decisões de roteamento, alocações de buffer ou transmissões cíclicas são processadas em tarefas periódicas das camadas superiores (por exemplo, SoAd_MainFunction) (SWS_SocketAdaptor p. 104). Como estruturas de ponteiro como PduInfoType podem ser compartilhadas entre o nível de interrupção e o nível de tarefa, a sincronização thread-safe por meio de Áreas Exclusivas (proteção contra concorrência) cabe aos módulos BSW chamadores e implementadores.

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

Definições de tipos puras não estão sujeitas a nenhum ciclo de vida em tempo de execução e não possuem funções de inicialização nem de encerramento (SWS_StandardTypes p. 27). Elas devem ser incluídas estaticamente em tempo de compilação antes de todos os módulos que as processam. No entanto, formam a estrutura normativa para mapear e monitorar o ciclo de vida de outros módulos BSW: para a consulta padronizada de versão, o std especifica a estrutura Std_VersionInfoType, que contém vendorID, moduleID bem como as versões de software (sw_major_version, sw_minor_version, sw_patch_version) ([SWS_Std_00015]).

Além disso, tipos como NetworkHandleType e PNCHandleType suportam o gerenciamento de rede e de modos de nível superior durante transições de modos de operação como startup, operação normal, sleep e wakeup ([SWS_COMTYPE_00036], [SWS_COMTYPE_00038]). Dessa forma, o ComM controla desligamentos coordenados e transições de estado na rede parcial com base nesses identificadores (SWS_COMManager p. 171, SWS_NetworkManagementInterface p. 106).

Tratamento de erros, rastreamento via DET e codificação de status

O cluster de módulos não disponibiliza nenhum tratamento de erro ativo próprio e não reporta erros de desenvolvimento ao DET nem erros de produção ao DEM (SWS_StandardTypes p. 27). Em vez disso, padroniza o formato de resposta em toda a plataforma: o tipo fundamental Std_ReturnType baseia-se em uint8 e serve em todas as camadas como resultado padrão de chamadas síncronas ([SWS_Std_00005], BSWUMLModelModelingGuide p. 28). Por padrão, E_OK (0x00u) representa a execução bem-sucedida e E_NOT_OK (0x01u) um erro genérico ([SWS_Std_00006]). Por motivos de compatibilidade com a ISO 17356-3 (OSEK OS), o E_OK é protegido contra definições múltiplas por meio de uma verificação de proteção (STATUSTYPEDEFINED) (AUTOSAR_SRS_BSWGeneral p. 62).

O layout de bits de Std_ReturnType segue um particionamento fixamente definido: os bits 0 a 5 (faixa de 0x00 a 0x3F) são reservados para valores de retorno padronizados e específicos de módulo ou códigos ApplicationError específicos da aplicação em operações cliente/servidor ([SWS_Std_00011], AUTOSAR_CP_SWS_StandardTypes p. 15). Extensões específicas de módulo são mantidas em modelos UML como uma classe com o estereótipo «extra_literals» (BSWUMLModelModelingGuide p. 33). Os bits 6 e 7 (faixa de valores 0x40, 0x80, 0xC0) são estritamente reservados para estados de erro de infraestrutura da RTE (AUTOSAR_CP_SWS_StandardTypes p. 15). Para transformações de dados na RTE, o std declara adicionalmente a estrutura Std_TransformerError, composta por errorCode ([SWS_Std_00022]) e transformerClass ([SWS_Std_00021]), permitindo rastrear integralmente cadeias de erros durante a serialização ou proteção E2E.