Communication Stack Types (ComStack_Types)

O módulo comstack fornece, através de ComStack_Types.h, os tipos comuns com os quais todas as camadas da pilha de comunicação Classic endereçam e trocam PDUs: PduIdType como identificador, PduLengthType como comprimento e PduInfoType com ponteiro de dados úteis, ponteiro de metadados e comprimento ([SWS_COMTYPE_00011]). Os protocolos de transporte copiam PDUs grandes de forma segmentada através de StartOfReception, CopyRxData e CopyTxData. Eles reportam o estado do buffer com BufReq_ReturnType, enquanto RetryInfoType controla confirmação e repetição ([SWS_COMTYPE_00012]). Condição de contorno mais importante: a largura de PduIdType e PduLengthType depende da configuração da EcuC e é gerada.

mais ›

O módulo comstack define o conjunto comum de tipos da pilha de comunicação Classic. A isso pertencem PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, RetryInfoType, bem como identificadores para canais e sub-redes, todos disponíveis através de ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00038]). Interfaces de barramento, protocolos de transporte, PduR, módulos de diagnóstico e a RTE utilizam os mesmos tipos; a RTE os importa expressamente (SWS RTE p. 833).

Diagrama de contexto: Um conjunto de tipos para todas as camadas, dimensionado através da configuração da EcuC. Fontes: [SWS_COMTYPE_00005], SWS RTE p. 833

Identificadores e comprimentos dependem da configuração. PduIdType é uint8 ou uint16, PduLengthType é uint8, uint16 ou uint32; ambos são gerados a partir da configuração da EcuC ([SWS_COMTYPE_00005], [SWS_COMTYPE_00008]). Cada módulo provedor escolhe seus IDs de identificador por conta própria. Eles precisam ser únicos apenas por API; o PduR os converte ao longo do caminho de roteamento (ECU Configuration p. 156).

PduInfoType agrupa ponteiro de dados úteis, ponteiro de metadados e comprimento. Dessa forma, a estrutura transporta solicitações de transmissão, indicações de recepção e Trigger Transmit. PDUs grandes são copiadas em partes: o protocolo de transporte chama repetidamente CopyTxData da camada superior através do PduR (SWS PduR p. 109). A recepção começa com StartOfReception e continua com CopyRxData.

Diagrama de sequências: O protocolo de transporte extrai os dados de transmissão do DCM em um laço; a confirmação segue ao final. Fontes: SWS PduR p. 109

Erros e gargalos são reportados por BufReq_ReturnType ([SWS_COMTYPE_00012]):

• BUFREQ_E_BUSY: temporariamente sem buffer ou dados insuficientes; a chamada pode ser repetida.
• BUFREQ_E_OVFL: nenhum buffer com o comprimento necessário.
• BUFREQ_E_NOT_OK: cancelamento.

A confirmação e a repetição durante a transmissão de TP são controladas por RetryInfoType com TP_DATACONF, TP_CONFPENDING e TP_DATARETRY, juntamente com o deslocamento TxTpDataCnt ([SWS_COMTYPE_00027], [SWS_COMTYPE_00037]).

Outros tipos de identificadores complementam o conjunto. NetworkHandleType (uint8) designa um canal de comunicação. TPParameterType seleciona STmin, Block Size ou controle de largura de banda para alteração ([SWS_COMTYPE_00031]). PNCHandleType é derivado no R20-11 de uint8 ([SWS_COMTYPE_00036]); a versão R23-11 indica, de forma divergente, uint16 (SWS ComStackTypes p. 17).

mais ›

Função: conjunto comum de tipos da pilha de comunicação

O módulo comstack não disponibiliza serviços próprios. Ele define os tipos de dados por meio dos quais os módulos da pilha de comunicação Classic comunicam-se entre si. A isso pertencem PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, TpDataStateType, RetryInfoType, TPParameterType, NetworkHandleType e PNCHandleType. Eles estão disponíveis através de ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00037], [SWS_COMTYPE_00038]). Interpretação: O módulo em si não possui comportamento em tempo de execução. Processos, estados e reações a erros só se originam nos módulos que utilizam esses tipos em suas interfaces. Pergunta Q-766338989232e06a (aberta)

A fronteira do sistema atravessa, portanto, toda a pilha. Os mesmos tipos são utilizados por:

• interfaces de barramento como CanIf e protocolos de transporte como CanTp (SWS CanIf p. 87),
• o PDU Router e módulos de diagnóstico como DCM (SWS PduR p. 109),
• SecOC (SWS SecOC p. 110),
• a RTE, que importa BufReq_ReturnType, PduIdType, PduInfoType, PduLengthType e RetryInfoType expressamente de ComStack_Types.h (SWS RTE p. 833).

Diagrama de contexto: Todas as camadas, desde a interface de barramento até a RTE, baseiam-se no mesmo conjunto de tipos de ComStack_Types.h; suas dimensões são geradas a partir da configuração da EcuC. Fontes: [SWS_COMTYPE_00005], SWS RTE p. 833, SWS PduR p. 33, SWS ComM p. 171

Identificadores e comprimentos de PDU: identidade e tamanho de uma PDU

PduIdType é um número inteiro de base zero no intervalo 0…<PduIdmax>. Sua largura (uint8 ou uint16) depende do número máximo de PDUs que um único módulo de software gerencia. A ferramenta geradora o cria a partir do valor configurado em ComStack_Cfg.h na camada virtual EcuC ([SWS_COMTYPE_00005]). O parâmetro associado PduIdTypeEnum define a regra: UINT8 é suficiente desde que nenhum módulo processe mais de 256 PDUs; caso contrário, é necessário UINT16 (ECU Configuration p. 153).

De forma análoga, PduLengthType é implementado dependendo da configuração como uint8, uint16 ou uint32. Determinante é o comprimento máximo das PDUs que uma unidade de controle eletrônico transmite ([SWS_COMTYPE_00008]). Os protocolos de transporte também derivam comprimentos da EcuC: o CanTp determina o comprimento máximo de transmissão da N-PDU a partir do parâmetro EcuC PduLength (SWS CanTp p. 60).

As APIs da pilha combinam duas coisas: um ponteiro para o buffer de dados da PDU e um ID de identificador que define a qual PDU esse ponteiro pertence. O módulo provedor escolhe livremente o valor do ID de identificador. Assim, a mesma PDU do Com com ID 5 pode ir para o PduR e, do PduR, ir com ID 19 para o CanIf. O ID precisa ser único apenas no escopo da respectiva API (ECU Configuration p. 156). Para que dois módulos possam referenciar a mesma PDU, existe na configuração de módulo virtual EcuC a EcucPduCollection (ECU Configuration p. 154) independente de módulo. O PduR identifica um caminho de roteamento por meio do ID de origem e dos IDs de destino, converte os IDs e repassa o valor de PduInfoType inalterado (SWS PduR p. 33).

Diagrama de colaboração: Cada interface possui IDs de identificador próprios; o PduR os converte, enquanto a PDU comum é referenciada através da EcucPduCollection. Fontes: ECU Configuration p. 156, ECU Configuration p. 154, SWS PduR p. 33

PduInfoType: dados úteis, metadados e comprimento em uma estrutura

PduInfoType agrupa três elementos ([SWS_COMTYPE_00011]):

• SduDataPtr aponta para os dados úteis.
• MetaDataPtr aponta para metadados, tais como CAN-ID, Socket-ID ou endereços de diagnóstico. Seu comprimento e tipo são configurados estaticamente por PDU; elementos com mais de 8 bits estão na ordem de bytes da plataforma.
• SduLength do tipo PduLengthType indica o comprimento da SDU em bytes.

A mesma estrutura suporta várias formas de interação:

• Solicitação de transmissão: <Mod>_Transmit(TxPduId, const PduInfoType*) passa o comprimento, o ponteiro de dados e o ponteiro de metadados, e retorna E_OK ou E_NOT_OK (SWS CanIf p. 87).
• Indicação de recepção: <Mod>_RxIndication(RxPduId, const PduInfoType*). No CanNm, o ponteiro de dados é válido apenas até o retorno da indicação (SWS CanNm p. 73).
• Trigger Transmit: PduInfoPtr é entrada e saída. Na chamada, SduLength contém o tamanho de buffer disponível; no retorno, o comprimento dos dados copiados (SWS CanIf p. 107). Na solicitação de transmissão anterior, a camada superior passa apenas o comprimento; SduDataPtr aponta então para NULL (SWS CanIf p. 158).
• Interfaces de cópia de TP: StartOfReception, CopyRxData e CopyTxData com retorno BufReq_ReturnType (SWS PduR p. 93).

Buffers do protocolo de transporte: cópia segmentada em vez de transferência direta

PDUs grandes não são transferidas como um todo. O transmissor busca os dados em partes: o DCM aciona CanTp_Transmit através do PduR. Em seguida, o CanTp chama repetidamente PduR_CanTpCopyTxData, que é encaminhado para Dcm_CopyTxData. Ao final estão PduR_CanTpTxConfirmation e Dcm_TpTxConfirmation (SWS PduR p. 109). Para os parâmetros de CopyTxData aplica-se:

• info fornece o buffer de destino e o número de bytes a serem copiados.
• Um SduLength igual a 0 apenas reporta uma mudança de estado no parâmetro retry ou consulta a quantidade disponível de dados; SduDataPtr pode então ser NULL_PTR (SWS PduR p. 93).
• availableDataPtr reporta os dados de transmissão restantes. Módulos TP com tamanho dinâmico de carga útil, como o FrIsoTp, dimensionam os Consecutive Frames subsequentes com base nisso (SWS LdCom p. 34).

Diagrama de sequências: Na transmissão por TP, o protocolo de transporte extrai os dados da camada superior em um laço através do PduR; a confirmação só segue após o último segmento. Fontes: SWS PduR p. 109, SWS PduR p. 93, [SWS_COMTYPE_00012]

A recepção ocorre em três etapas:

1. StartOfReception abre a conexão. info transporta os dados do First Frame ou Single Frame juntamente com os metadados, ou é NULL_PTR caso nenhum dos dois esteja presente. TpSduLength informa o comprimento total. Através de bufferSizePtr, o receptor reporta seu buffer livre; o protocolo de transporte calcula a Block Size a partir disso (SWS PduR p. 92).
2. Cada chamada de CopyRxData fornece a próxima parte da I-PDU e grava de volta o buffer restante (SWS PduR p. 91).
3. Uma RxIndication conclui a recepção.

Se uma TP-PDU for adicionalmente roteada por gateway, o próprio PduR a armazena em buffer, pois o DCM não tem ciência do gatewaying (SWS PduR p. 112).

Diagrama de sequências: A recepção por TP começa com uma negociação de buffer, continua de forma segmentada e termina com a indicação. Fontes: SWS PduR p. 112, SWS PduR p. 92, SWS PduR p. 91

Confirmação e repetição: RetryInfoType e TpDataStateType

RetryInfoType contém dois campos ([SWS_COMTYPE_00037]):

• TpDataState descreve o estado do buffer de TP.
• TxTpDataCnt indica o deslocamento a partir da posição atual, que determina o número de bytes a serem reenviados.

TpDataStateType reconhece três valores ([SWS_COMTYPE_00027]):

• TP_DATACONF: Todos os dados copiados até o momento estão confirmados e podem ser removidos do buffer de TP. Os dados copiados nesta chamada estão excluídos disso.
• TP_DATARETRY: Dados já copiados são copiados novamente para corrigir um erro. TxTpDataCnt indica o deslocamento inicial.
• TP_CONFPENDING: Os dados copiados até o momento devem permanecer no buffer de TP para o tratamento de erros.

Se o próprio retry for NULL_PTR, os dados podem ser liberados imediatamente após a cópia (SWS PduR p. 93).

Diagrama de atividades: Uma chamada de CopyTxData avalia primeiro o parâmetro retry e decide então sobre a cópia ou BUFREQ_E_BUSY. Fontes: SWS PduR p. 93, [SWS_COMTYPE_00027], [SWS_COMTYPE_00012]

O diagrama do protocolo de transporte J1939 ilustra a interação concretamente:

• Por bloco, o primeiro pacote é solicitado com TP_DATACONF, e os seguintes com TP_CONFPENDING.
• Se um TP.DT for perdido, a transmissão recomeça no primeiro pacote do bloco. Para isso, TP_DATARETRY é definido e TxTpDataCnt contém o deslocamento para o início do bloco (SWS J1939Tp p. 55).

Nem todo usuário avalia o parâmetro: No LdCom, segundo a especificação, retry não é tratado nem pelo LdCom nem por sua camada superior (SWS LdCom p. 34).

Diagrama de sequência: Transmissão em blocos com estados de confirmação e retorno ao início do bloco em caso de perda de pacote de dados. Fontes: SWS J1939Tp p. 55, [SWS_COMTYPE_00027], [SWS_COMTYPE_00037]

Canais, sub-redes e parâmetros de TP

NetworkHandleType é um uint8 com o intervalo de base zero 0..255. Ele armazena o identificador de um canal de comunicação ([SWS_COMTYPE_00038]). Exemplos de releases posteriores:

• O Bus Mirroring relata um frame LIN com o canal ComM atribuído ao canal LIN (SWS Mirror p. 80).
• O J1939Dcm passa o canal no qual uma requisição foi recebida (SWS J1939Dcm p. 67).

PNCHandleType armazena o identificador de um Partial Network Cluster e é derivado de uint8 na R20-11 ([SWS_COMTYPE_00036]). O trecho documental da R23-11 menciona, por outro lado, uint16 (SWS ComStackTypes p. 17). Para a R20-11, aplica-se o requisito. O contexto de aplicação dos identificadores PNC é demonstrado, por exemplo, pelo desligamento sincronizado de PNC no ComM (SWS ComM p. 171).

TPParameterType especifica o parâmetro do protocolo de transporte cujo valor deve ser modificado ([SWS_COMTYPE_00031]):

• TP_STMIN: Separation Time,
• TP_BS: Block Size,
• TP_BC: controle de largura de banda do protocolo de transporte FlexRay.

Block Size e STmin aparecem, por exemplo, no frame Flow Control do protocolo de transporte FlexRay-AR (SWS FrArTp p. 47).

Comportamento em caso de erro

O resultado de uma solicitação de buffer é descrito por BufReq_ReturnType ([SWS_COMTYPE_00012]):

• BUFREQ_OK (0): com sucesso.
• BUFREQ_E_NOT_OK (1): O buffer não está acessível.
• BUFREQ_E_BUSY (2): Temporariamente nenhum buffer está disponível; o solicitante deve tentar novamente durante um determinado período.
• BUFREQ_E_OVFL (3): Não é possível disponibilizar nenhum buffer com o comprimento necessário.

As interfaces mapeiam esses valores da seguinte forma:

• CopyTxData: Se os dados de transmissão forem insuficientes, nada é copiado e BUFREQ_E_BUSY é retornado; a camada inferior pode repetir a chamada (SWS PduR p. 93). No fluxo de buffer paginado do DCM, BUFREQ_E_BUSY ocorre alternando com a preparação da próxima página (SWS DCM p. 481).
• StartOfReception: BUFREQ_E_NOT_OK rejeita a conexão e aborta a recepção; bufferSizePtr permanece inalterado. BUFREQ_E_OVFL aborta porque nenhum buffer com o comprimento necessário está disponível. Com BUFREQ_OK sem buffer do tamanho solicitado, um tamanho de buffer de 0 é relatado (SWS DCM p. 273).
• CopyRxData: BUFREQ_E_NOT_OK significa que nada foi copiado devido a um erro (SWS PduR p. 91).
• Erro de transmissão no TP: A correção ocorre via TP_DATARETRY com o deslocamento TxTpDataCnt ([SWS_COMTYPE_00027]).
• TriggerTransmit: E_NOT_OK significa que nada foi copiado. PduInfoPtr não deve ser utilizado nesse caso, pois pode ser NULL ou inválido (SWS CanIf p. 107).

Outras verificações são definidas pelos próprios módulos usuários. Exemplos:

• DoIP_SoAdTpCopyRxData verifica, quando a detecção de erros de desenvolvimento está ativada, se DoIP_Init foi chamado previamente (SWS DoIP p. 77).
• FrIf_Transmit retorna no estado FRIF_STATE_OFFLINE o valor E_NOT_OK (SWS FrIf p. 68).
• Muitas dessas funções são reentrantes apenas para diferentes IDs de PDU, não para a mesma (SWS DoIP p. 75).

Evidências mais detalhadas

A visão geral a seguir classifica as principais referências ([SWS_COMTYPE_00005] a [SWS_COMTYPE_00038]):

Referência	Classificação
[SWS_COMTYPE_00005], [SWS_COMTYPE_00008]	Largura dependente da configuração de PduIdType e PduLengthType, gerada a partir do EcuC
[SWS_COMTYPE_00011]	Estrutura de PduInfoType incluindo metadados
[SWS_COMTYPE_00012]	Códigos de resultado de todas as solicitações de buffer de TP
[SWS_COMTYPE_00027], [SWS_COMTYPE_00037]	Lógica de confirmação e repetição na transmissão de TP
[SWS_COMTYPE_00031], [SWS_COMTYPE_00036], [SWS_COMTYPE_00038]	Seleção de parâmetros de TP, identificadores PNC e de canal
ECU Configuration S. 156	Conceito de Handle ID: valores livremente selecionáveis por módulo, exclusivos por API
SWS PduR S. 93, SWS PduR S. 92	Semântica de referência das interfaces de cópia de TP
SWS J1939Tp S. 55	Diagrama do tratamento de retry (também indicado para a R20-11)