CAN Transport Layer (CanTp)

La CAN Transport Layer divide los mensajes que no caben en una trama CAN, gestiona el flujo de datos mediante Flow Control y vuelve a ensamblar los segmentos recibidos según ISO 15765-2 [SWS_CanTp_00033]. Se sitúa entre PduR y CanIf, no dispone de búfer de datos útiles propio y copia los datos de transmisión y recepción por segmentos mediante los servicios de copia de la capa superior [SWS_CanTp_00298]. Concluye cada transferencia aceptada con una notificación a la capa superior: de forma exitosa con E_OK; en caso de tiempo de espera o cancelación, con E_NOT_OK. Todo esto presupone CanTp_Init; la MainFunction periódica supervisa los tiempos de espera.

más ›

CanTp es la CAN Transport Layer. Divide mensajes largos en tramas CAN, gestiona el flujo de datos y vuelve a ensamblar los segmentos recibidos; al hacerlo, sigue la norma ISO 15765-2 en la medida en que la especificación no disponga lo contrario [SWS_CanTp_00033]. El módulo se ubica entre PduR y CanIf y no dispone de un búfer de datos útiles propio. Copia los datos por segmentos a través de los servicios de copia de la capa superior [SWS_CanTp_00298] [SWS_CanTp_00216].

Diagrama de contexto: las interfaces de CanTp con PduR, CanIf, la gestión de modos, el planificador y DET. Fuentes: [SWS_CanTp_00216], SWS CanTp p. 17

Tras el encendido, CanTp se encuentra en CANTP_OFF [SWS_CanTp_00168]. CanTp_Init con CanTp_ConfigType [SWS_CanTp_00208] pone todas las conexiones en estado de reposo [SWS_CanTp_00030]; a partir de entonces rige CANTP_ON [SWS_CanTp_00170]. CanTp_Shutdown cierra todas las conexiones sin notificar a nadie [SWS_CanTp_00202] [SWS_CanTp_00200]. Los canales de conexión operan de forma independiente entre sí con temporizadores propios [SWS_CanTp_00122]. Si un canal de transmisión está ocupado, CanTp rechaza nuevas órdenes con E_NOT_OK [SWS_CanTp_00123].

Al transmitir, CanTp_Transmit evalúa únicamente la longitud (y, en su caso, MetaData) [SWS_CanTp_00225]. Según la longitud, sigue un SF o una sesión segmentada [SWS_CanTp_00232]. Para cada segmento, CanTp obtiene los datos con PduR_CanTpCopyTxData [SWS_CanTp_00086] y, tras el FF y cada bloque bajo N_Bs, espera el Flow Control [SWS_CanTp_00315]. Interpretación: la llamada solo notifica la aceptación; el fin de la transferencia llega de forma asíncrona mediante PduR_CanTpTxConfirmation [SWS_CanTp_00176] [SWS_CanTp_00204]. Pregunta (abierta)

Al recibir, CanTp solicita primero un búfer con PduR_CanTpStartOfReception [SWS_CanTp_00079]. A continuación, copia cada CF con PduR_CanTpCopyRxData [SWS_CanTp_00269]. Si el búfer es escaso, CanTp vuelve a consultarlo en cada MainFunction y envía como máximo WFTmax FC(WAIT) [SWS_CanTp_00222] [SWS_CanTp_00223]. Al final se produce PduR_CanTpRxIndication [SWS_CanTp_00084]. La CanTp_MainFunction periódica supervisa los tiempos de espera [SWS_CanTp_00164].

Diagrama de secuencias: recepción segmentada con negociación de búfer y Flow Control CTS/WAIT. Fuentes: [SWS_CanTp_00269], [SWS_CanTp_00222], SWS CanTp p. 38

CanTp gestiona los errores de tres formas. Notifica los errores de desarrollo a DET y devuelve E_NOT_OK [SWS_CanTp_00294]. Los errores de protocolo, como los tiempos de espera, cancelan la sesión y se comunican con E_NOT_OK a PduR [SWS_CanTp_00205] [SWS_CanTp_00311]. Lo mismo aplica para cancelaciones a petición mediante los servicios Cancel [SWS_CanTp_00255] [SWS_CanTp_00263]. Para IDs no válidos en los servicios Cancel, R20-11 exige CANTP_E_PARAM_ID [SWS_CanTp_00254], mientras que versiones más recientes indican otros códigos.

más ›

Rol en la pila CAN: protocolo de transporte entre PduR y CanIf

CanTp es la CAN Transport Layer. Divide los mensajes que no caben en una única trama CAN en segmentos, controla el flujo de datos y vuelve a ensamblar los segmentos recibidos (SWS CanTp p. 24, SWS CanTp p. 17). La base es ISO 15765-2: se aplica cualquier recomendación de dicha norma, salvo que la especificación la excluya expresamente [SWS_CanTp_00033]. CanTp solo realiza la segmentación y el reensamblaje en el estado CANTP_ON [SWS_CanTp_00238].

Hacia arriba, CanTp proporciona a PduR los siguientes servicios: CanTp_Transmit [SWS_CanTp_00212], CanTp_CancelTransmit [SWS_CanTp_00246] y CanTp_CancelReceive [SWS_CanTp_00257]. Por sí mismo, CanTp llama hacia arriba a PduR_CanTpStartOfReception, PduR_CanTpCopyRxData, PduR_CanTpCopyTxData, PduR_CanTpRxIndication y PduR_CanTpTxConfirmation, y hacia abajo a CanIf_Transmit [SWS_CanTp_00216]. La capa inferior notifica las tramas recibidas mediante CanTp_RxIndication [SWS_CanTp_00078] y las confirmaciones de transmisión mediante CanTp_TxConfirmation [SWS_CanTp_00076]. Ambas funciones deben poder ser llamadas en contexto de interrupción [SWS_CanTp_00235] [SWS_CanTp_00236]. Pasajes más recientes del documento nombran como invocador al L-SDU Router (LSduR) (SWS CanTp p. 27). En cambio, los requirements de R20-11 hacen referencia a CAN Interface, por ejemplo [SWS_CanTp_00031] y [SWS_CanTp_00335].

CanTp no dispone de un búfer de datos útiles propio. Obtiene los datos de transmisión directamente de la capa superior [SWS_CanTp_00298] y copia los datos recibidos de manera inmediata en la memoria de esta (SWS CanTp p. 35). De esto se derivan periodos de bloqueo para la capa superior (SWS CanTp p. 35):

• Mantiene bloqueado el búfer de transmisión tan pronto como CanTp_Transmit retorna con E_OK, hasta que llega PduR_CanTpTxConfirmation.
• Mantiene bloqueado el búfer de recepción tan pronto como ha entregado BUFREQ_OK en PduR_CanTpStartOfReception, hasta que llega PduR_CanTpRxIndication.

Diagrama de contexto: CanTp se sitúa entre PduR y CanIf. Es inicializado por la gestión de modos, activado cíclicamente por el scheduler y notifica errores a DET. Fuentes: [SWS_CanTp_00216], [SWS_CanTp_00217], [SWS_CanTp_00164], SWS CanTp p. 17, Mode Management Guide p. 54

Ciclo de vida: CANTP_OFF, CanTp_Init y canales de conexión independientes

CanTp reconoce los estados CANTP_OFF y CANTP_ON [SWS_CanTp_00027]. Tras el encendido, el módulo se encuentra en CANTP_OFF [SWS_CanTp_00168]; únicamente allí se permite actualizar la configuración post-build [SWS_CanTp_00169].

CanTp_Init recibe un puntero a CanTp_ConfigType [SWS_CanTp_00208] [SWS_CanTp_00340]. La función inicializa todas las variables globales y sitúa cada conexión en el estado de reposo CANTP_RX_WAIT o CANTP_TX_WAIT [SWS_CanTp_00030]; a partir de entonces rige CANTP_ON [SWS_CanTp_00170]. El entorno debe llamar a CanTp_Init antes de cualquier uso posterior [SWS_CanTp_00199]. En la guía de gestión de modos, esto lo asume una regla de BswM tras NvM_ReadAll (Mode Management Guide p. 54). Una nueva llamada en CANTP_ON descarta todas las conexiones en curso y devuelve al estado de reposo [SWS_CanTp_00273] [SWS_CanTp_00111].

CanTp_Shutdown cierra todas las conexiones abiertas, libera los recursos y establece CANTP_OFF [SWS_CanTp_00202]. Al hacerlo, CanTp no notifica a nadie sobre las transmisiones canceladas [SWS_CanTp_00200] (SWS CanTp p. 58).

En CANTP_ON se ejecutan varias conexiones simultáneamente [SWS_CanTp_00096]:

• Cada N-SDU está asignada estáticamente a un canal de conexión. Cada canal cuenta con temporizadores propios, búferes y una máquina de estados propia [SWS_CanTp_00121] [SWS_CanTp_00122].
• Los canales solo son visibles internamente [SWS_CanTp_00285]. Su número lo determina la herramienta de configuración [SWS_CanTp_00289].
• Si un canal de transmisión está en CANTP_TX_PROCESSING, CanTp rechaza nuevas solicitudes a través de CanTp_Transmit con E_NOT_OK [SWS_CanTp_00123]. Lo mismo rige para una N-SDU que ya se encuentre en una sesión en curso [SWS_CanTp_00206].
• Si varias N-SDU comparten un canal y no hay ningún canal libre disponible, CanTp rechaza la transmisión o interrumpe la recepción [SWS_CanTp_00288] (SWS CanTp p. 42).

Diagrama de estados: tras CanTp_Init, los canales de recepción y transmisión alternan de forma independiente entre WAIT y PROCESSING; CanTp_Shutdown devuelve a CANTP_OFF. Fuentes: [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00170], [SWS_CanTp_00202], SWS CanTp p. 27

Transmisión: desde CanTp_Transmit hasta la confirmación

CanTp_Transmit recibe TxPduId y PduInfoPtr [SWS_CanTp_00212]. Sin MetaData, CanTp solo evalúa la longitud total SduLength y no accede al búfer de datos [SWS_CanTp_00225] [SWS_CanTp_00299]. Con MetaData, almacena adicionalmente la información de direccionamiento para todos los SF, FF y CF [SWS_CanTp_00334]. Si los datos caben en una N-PDU, CanTp envía un SF; de lo contrario, abre una sesión de múltiples tramas [SWS_CanTp_00232] (SWS CanTp p. 60). La longitud máxima de transmisión (TX_DL) se deriva de PduLength en EcuC [SWS_CanTp_00354]. Interpretación: la llamada notifica de forma síncrona únicamente si la solicitud ha sido aceptada; la transferencia propiamente dicha se ejecuta de forma asíncrona [SWS_CanTp_00176]. Pregunta Q-b6d13590324e2906 (abierta) Tras la aceptación, CanTp notifica el final en cualquier caso mediante PduR_CanTpTxConfirmation [SWS_CanTp_00177] [SWS_CanTp_00204].

Para cada segmento (SF, FF, CF), CanTp llama a PduR_CanTpCopyTxData [SWS_CanTp_00086]; hasta la primera llamada, se ejecuta el temporizador N_Cs [SWS_CanTp_00167]. Si la capa superior devuelve BUFREQ_E_BUSY, CanTp lo intenta de nuevo más tarde [SWS_CanTp_00184]. CanTp establece el parámetro retry siempre a NULL, debido a que ISO 15765-2 no contempla la repetición [SWS_CanTp_00272].

Tras el FF y tras el último CF de cada bloque, CanTp espera bajo N_Bs una trama Flow Control [SWS_CanTp_00315]. Con ella, el receptor habilita más CF o los retrasa [SWS_CanTp_00282]. Si la sesión concluye con éxito, sigue PduR_CanTpTxConfirmation con E_OK [SWS_CanTp_00090]. El mismo flujo pull lo muestran el ejemplo de 50 bytes (SWS CanTp p. 37) y la ruta de DCM a CanTp (SWS PduR p. 104).

Diagrama de secuencias: CanTp solicita los datos por segmentos a PduR, espera tras el FF y tras cada bloque a Flow Control y confirma al final con E_OK. Fuentes: [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00315], [SWS_CanTp_00090], SWS CanTp p. 73

Recepción: negociación de búfer, Flow Control y reensamblado

Con cada SF o FF entrante, CanTp notifica el inicio de la recepción con PduR_CanTpStartOfReception [SWS_CanTp_00079]. El tamaño de búfer disponible se devuelve a través de un parámetro de salida y puede ser menor que la N-SDU [SWS_CanTp_00080]. En caso de un FF, CanTp inicia previamente el temporizador N_Br [SWS_CanTp_00166]. Envía el Flow Control solo cuando el resultado está disponible; su contenido depende de dicho resultado [SWS_CanTp_00064] [SWS_CanTp_00277]. Todos los FC de una sesión de recepción llevan los mismos valores para BS y STmin [SWS_CanTp_00067]. Un FC sigue respectivamente tras BS Consecutive Frames [SWS_CanTp_00278].

Tras cada CF, CanTp entrega los datos útiles con PduR_CanTpCopyRxData y obtiene con ello el búfer restante [SWS_CanTp_00269]. En CAN 2.0, esto son seis o siete bytes por CF. Si tras el último CF de un bloque el búfer restante no basta para el siguiente bloque, CanTp inicia el temporizador N_Br [SWS_CanTp_00325] [SWS_CanTp_00082]. Mientras este temporizador esté en marcha:

• CanTp consulta el búfer en cada ciclo de la MainFunction, concretamente con longitud 0 y NULL_PTR [SWS_CanTp_00222];
• CanTp envía como máximo WFTmax FC(WAIT) consecutivos [SWS_CanTp_00223] (SWS CanTp p. 38).

Si la sesión finaliza, sea con éxito o no, CanTp llama a PduR_CanTpRxIndication [SWS_CanTp_00084]. Con y sin padding, CanTp solo pasa hacia arriba los bytes de datos efectivamente utilizados [SWS_CanTp_00116].

Diagrama de secuencias: recepción segmentada con negociación de búfer, Flow Control por bloques y fase de espera en caso de búfer escaso. Fuentes: [SWS_CanTp_00079], [SWS_CanTp_00269], [SWS_CanTp_00222], [SWS_CanTp_00084], SWS CanTp p. 76

Diagrama de actividades: así decide CanTp ante un SF o FF entrante en función del estado del canal y del resultado de PduR_CanTpStartOfReception. Fuentes: [SWS_CanTp_00124], [SWS_CanTp_00337], [SWS_CanTp_00081], [SWS_CanTp_00318], [SWS_CanTp_00353], SWS CanTp p. 67

Direccionamiento, MetaData y padding

El direccionamiento funcional (1:n) solo está permitido para SF [SWS_CanTp_00092]. CanTp rechaza una sesión segmentada a través de un handle funcional y notifica CANTP_E_INVALID_TATYPE [SWS_CanTp_00093] (SWS CanTp p. 39). En caso de Extended o Mixed Addressing, CanTp determina la N-SDU a partir de N_TA o N_AE en el primer byte de datos [SWS_CanTp_00095] [SWS_CanTp_00284] [SWS_CanTp_00283]. Para la asignación de los identificadores rige (SWS CanTp p. 44):

• Cada NSduId está asignada exactamente a una LSduId [SWS_CanTp_00035].
• La LSduId de un FC identifica, junto con N_TA o N_AE, exactamente una NSduId [SWS_CanTp_00094].
• Múltiples N-SDU solo pueden hacer referencia a la misma N-PDU en caso de Extended/Mixed Addressing o con MetaData [SWS_CanTp_00328].

Las conexiones genéricas operan con MetaData. CanTp guarda la información de direccionamiento de SF o FF [SWS_CanTp_00330], la reenvía a PduR_CanTpStartOfReception [SWS_CanTp_00331] y valida los CF siguientes frente a ella [SWS_CanTp_00333]. Si el canal ya está recibiendo, CanTp ignora un SF o FF adicional con MetaData [SWS_CanTp_00337].

El padding se activa por cada N-SDU (SWS CanTp p. 43). El valor de relleno es CANTP_PADDING_BYTE [SWS_CanTp_00059]. Para tramas con una carga útil máxima de 8 bytes rige:

• Con Rx-Padding, CanTp solo acepta SF y el último CF con 8 bytes [SWS_CanTp_00344] y envía FC con 8 bytes [SWS_CanTp_00347].
• Con Tx-Padding, CanTp rellena SF y el último CF hasta 8 bytes [SWS_CanTp_00348].

Si una longitud de transmisión no encaja con ningún DLC válido, CanTp rellena hasta el siguiente valor válido superior [SWS_CanTp_00351]. CanTp deriva la longitud de recepción RX_DL a partir del primer CAN_DL recibido [SWS_CanTp_00350].

Supervisión temporal, parámetros en tiempo de ejecución y cancelación bajo petición

CanTp_MainFunction [SWS_CanTp_00213] se llama cíclicamente. Supervisa N_As, N_Bs, N_Cs, N_Ar, N_Br, N_Cr así como STmin [SWS_CanTp_00164] (SWS CanTp p. 63). Su cadencia se rige por CanTpMainFunctionPeriod [SWS_CanTp_00300]. Este valor debe corresponder al tiempo de ciclo de la tarea invocadora (SWS CanTp p. 77). Como ejemplo, el análisis de temporización menciona una tarea de 5 ms (TR Timing Analysis p. 117).

Dos servicios acceden en tiempo de ejecución a los parámetros de recepción BS y STmin de una N-SDU: CanTp_ChangeParameter los modifica [SWS_CanTp_00302], CanTp_ReadParameter los lee [SWS_CanTp_00323]. Ambos existen solo si CanTpChangeParameterApi = TRUE (SWS CanTp p. 61). BS es únicamente un valor máximo, que CanTp puede reducir por razones de búfer [SWS_CanTp_00091]. Entre FF y el último CF de una sesión de recepción en curso, CanTp rechaza cualquier modificación con E_NOT_OK [SWS_CanTp_00303] [SWS_CanTp_00304]. En conexiones genéricas, una modificación es válida para todas [SWS_CanTp_00338].

Las transmisiones en curso pueden cancelarse bajo petición:

• Transmisión: la función se activa estáticamente mediante CanTpTc [SWS_CanTp_00242] y se desencadena con CanTp_CancelTransmit [SWS_CanTp_00274]. En caso de E_OK, CanTp cancela la transmisión [SWS_CanTp_00243] [SWS_CanTp_00256] y notifica PduR_CanTpTxConfirmation con E_NOT_OK [SWS_CanTp_00255]. En el extremo opuesto, esto conduce a un timeout (SWS CanTp p. 26).
• Recepción: CanTp_CancelReceive finaliza una recepción iniciada con FF [SWS_CanTp_00261] y notifica PduR_CanTpRxIndication con E_NOT_OK [SWS_CanTp_00263]. En el caso de un SF o si únicamente queda pendiente el último CF, CanTp rechaza la cancelación [SWS_CanTp_00262] (SWS CanTp p. 60).

Comportamiento en caso de error

Errores de desarrollo. Si la detección está activa, CanTp notifica el error a DET y devuelve E_NOT_OK [SWS_CanTp_00294] [SWS_CanTp_00217] (SWS CanTp p. 49). Los códigos los define [SWS_CanTp_00293]. Casos típicos:

• CANTP_E_UNINIT: se utiliza una función distinta de CanTp_GetVersionInfo antes de CanTp_Init [SWS_CanTp_00031].
• CANTP_E_PARAM_POINTER: un puntero es NULL [SWS_CanTp_00319] [SWS_CanTp_00321] [SWS_CanTp_00322].
• CANTP_E_PARAM_ID: CanTp_ReadParameter recibe parámetros no válidos [SWS_CanTp_00324].

Discrepancia entre las versiones: para un PduId no válido en los servicios de cancelación, R20-11 exige CANTP_E_PARAM_ID [SWS_CanTp_00254] [SWS_CanTp_00260]. Pasajes más recientes del documento nombran en su lugar CANTP_E_INVALID_TX_ID o CANTP_E_INVALID_RX_ID (SWS CanTp p. 59). Para R20-11 se aplica el requirement.

Errores en tiempo de ejecución. Se envían al Default Error Tracer [SWS_CanTp_00352]:

• CANTP_E_PADDING: una trama es demasiado corta a pesar del padding [SWS_CanTp_00345] [SWS_CanTp_00346] [SWS_CanTp_00349].
• CANTP_E_OPER_NOT_SUPPORTED: un cancel afecta a una N-SDU sin transmisión en curso [SWS_CanTp_00254].
• Para errores de protocolo, el pasaje del documento menciona adicionalmente CANTP_E_COM, CANTP_E_RX_COM y CANTP_E_TX_COM (SWS CanTp p. 52).

Errores de protocolo. Finalizan la sesión con E_NOT_OK hacia la capa superior [SWS_CanTp_00205]:

• Lado de transmisión (notificación mediante PduR_CanTpTxConfirmation): falta de datos al copiar [SWS_CanTp_00087], expiración de N_Cs [SWS_CanTp_00280], N_As [SWS_CanTp_00310] o N_Bs [SWS_CanTp_00316], FC con OVFLW o FS no válido [SWS_CanTp_00309] [SWS_CanTp_00317]. Tras N_As, la N-PDU permanece bloqueada hasta que llega la TxConfirmation [SWS_CanTp_00075].
• Lado de recepción (notificación mediante PduR_CanTpRxIndication): expiración de N_Ar [SWS_CanTp_00311] o N_Cr [SWS_CanTp_00313], copia rechazada [SWS_CanTp_00271].
• Cancelación sin notificación: si PduR_CanTpStartOfReception devuelve BUFREQ_E_NOT_OK, CanTp cancela; no siguen ni FC ni Indication [SWS_CanTp_00081].
• CanTp trata las N-PDU inesperadas de acuerdo con una tabla [SWS_CanTp_00057] (SWS CanTp p. 45).

PduR reenvía la confirmación negativa al usuario, por ejemplo a DCM, que luego se encarga de la recuperación (Error Description p. 29, Error Description p. 28). Dem gestiona los errores de producción a través de FiM [SWS_CanTp_00291].

Diagrama de actividades: todas las causas de cancelación desembocan por cada dirección en una notificación negativa a PduR. Fuentes: [SWS_CanTp_00205], [SWS_CanTp_00343], [SWS_CanTp_00355], [SWS_CanTp_00342], [SWS_CanTp_00223], [SWS_CanTp_00084], Error Description p. 28

Más evidencia detallada

• Ciclo de vida y canales: [SWS_CanTp_00027], [SWS_CanTp_00030], [SWS_CanTp_00122]; autómata de estados en SWS CanTp p. 27.
• Transmisión: [SWS_CanTp_00212], [SWS_CanTp_00086], [SWS_CanTp_00204]; flujo de ejemplo en SWS CanTp p. 37.
• Recepción y búfer: [SWS_CanTp_00079], [SWS_CanTp_00222]; ejemplo de 49 bytes en SWS CanTp p. 38.
• Supervisión temporal: [SWS_CanTp_00164], [SWS_CanTp_00300].
• Direccionamiento y padding: [SWS_CanTp_00092], [SWS_CanTp_00330], [SWS_CanTp_00344]; trasfondo en SWS CanTp p. 43.
• Códigos de error: [SWS_CanTp_00293] (errores de desarrollo), [SWS_CanTp_00352] (errores en tiempo de ejecución); tabla de N-PDU inesperadas en [SWS_CanTp_00057].