Communication Stack Types (ComStack_Types)

El módulo comstack proporciona a través de ComStack_Types.h los tipos comunes con los que todas las capas de la pila de comunicación Classic direccionan e intercambian PDU: PduIdType como identificador (handle), PduLengthType como longitud y PduInfoType con puntero de datos útiles, puntero de metadatos y longitud ([SWS_COMTYPE_00011]). Los protocolos de transporte copian PDU grandes por segmentos mediante StartOfReception, CopyRxData y CopyTxData. Notifican el estado del búfer con BufReq_ReturnType, mientras que RetryInfoType controla la confirmación y la repetición ([SWS_COMTYPE_00012]). Condición límite principal: el ancho de PduIdType y PduLengthType depende de la configuración de EcuC y se genera.

más ›

El módulo comstack define el conjunto de tipos comunes de la pila de comunicación Classic. Entre ellos se encuentran PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, RetryInfoType, así como identificadores de canales y subredes, todos disponibles a través de ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00038]). Las interfaces de bus, los protocolos de transporte, PduR, los módulos de diagnóstico y la RTE utilizan los mismos tipos; la RTE los importa expresamente (SWS RTE p. 833).

Diagrama de contexto: un conjunto de tipos para todas las capas, dimensionado a través de la configuración de EcuC. Fuentes: [SWS_COMTYPE_00005], SWS RTE p. 833

Los handles y las longitudes dependen de la configuración. PduIdType es uint8 o uint16, PduLengthType es uint8, uint16 o uint32; ambos se generan a partir de la configuración de EcuC ([SWS_COMTYPE_00005], [SWS_COMTYPE_00008]). Cada módulo proveedor elige sus propios handle ID. Solo deben ser únicos por cada API; el PduR los traduce a lo largo de la ruta de enrutamiento (ECU Configuration p. 156).

PduInfoType agrupa el puntero de datos útiles, el puntero de metadatos y la longitud. Con ello, la estructura soporta solicitudes de transmisión, indicaciones de recepción y Trigger Transmit. Las PDU grandes se copian por fragmentos: el protocolo de transporte llama repetidamente a CopyTxData de la capa superior a través del PduR (SWS PduR p. 109). La recepción comienza con StartOfReception y continúa con CopyRxData.

Diagrama de secuencia: el protocolo de transporte extrae los datos de transmisión del DCM en un bucle; la confirmación sigue al final. Fuentes: SWS PduR p. 109

BufReq_ReturnType notifica errores y situaciones de escasez ([SWS_COMTYPE_00012]):

• BUFREQ_E_BUSY: temporalmente sin búfer o datos insuficientes; se permite reintentar la llamada.
• BUFREQ_E_OVFL: no hay búfer de la longitud requerida.
• BUFREQ_E_NOT_OK: cancelación.

RetryInfoType controla la confirmación y la repetición durante la transmisión TP con TP_DATACONF, TP_CONFPENDING y TP_DATARETRY junto con el desplazamiento (offset) TxTpDataCnt ([SWS_COMTYPE_00027], [SWS_COMTYPE_00037]).

Otros tipos de identificadores complementan el repertorio. NetworkHandleType (uint8) designa un canal de comunicación. TPParameterType selecciona STmin, Block Size o control de ancho de banda para su modificación ([SWS_COMTYPE_00031]). En R20-11, PNCHandleType se deriva de uint8 ([SWS_COMTYPE_00036]); la versión de R23-11 menciona de forma divergente uint16 (SWS ComStackTypes p. 17).

más ›

Rol: conjunto común de tipos de la pila de comunicación

El módulo comstack no proporciona servicios propios. Define los tipos de datos a través de los cuales los módulos de la pila de comunicación Classic se comunican entre sí. Entre ellos se incluyen PduIdType, PduLengthType, PduInfoType, BufReq_ReturnType, TpDataStateType, RetryInfoType, TPParameterType, NetworkHandleType y PNCHandleType. Están disponibles mediante ComStack_Types.h ([SWS_COMTYPE_00011], [SWS_COMTYPE_00037], [SWS_COMTYPE_00038]). Interpretación: por tanto, el módulo no posee por sí mismo comportamiento en tiempo de ejecución. Pregunta Q-766338989232e06a (abierta) Las secuencias, los estados y las reacciones ante errores solo se originan en los módulos que utilizan estos tipos en sus interfaces.

Por este motivo, el límite del sistema atraviesa toda la pila. Utilizan los mismos tipos:

• interfaces de bus como CanIf y protocolos de transporte como CanTp (SWS CanIf p. 87),
• el PDU Router y módulos de diagnóstico como DCM (SWS PduR p. 109),
• SecOC (SWS SecOC p. 110),
• la RTE, que importa BufReq_ReturnType, PduIdType, PduInfoType, PduLengthType y RetryInfoType expresamente desde ComStack_Types.h (SWS RTE p. 833).

Diagrama de contexto: todas las capas, desde la interfaz de bus hasta la RTE, se basan en el mismo conjunto de tipos de ComStack_Types.h; sus tamaños se generan a partir de la configuración de EcuC. Fuentes: [SWS_COMTYPE_00005], SWS RTE p. 833, SWS PduR p. 33, SWS ComM p. 171

Handles de PDU y longitudes: identidad y tamaño de una PDU

PduIdType es un número entero con base cero en el rango 0…<PduIdmax>. Su anchura (uint8 o uint16) depende del número máximo de PDU que gestiona un módulo de software individual. La herramienta generadora lo genera a partir del valor configurado en ComStack_Cfg.h dentro de la capa virtual de EcuC ([SWS_COMTYPE_00005]). El parámetro correspondiente PduIdTypeEnum establece la regla: UINT8 es suficiente mientras ningún módulo gestione más de 256 PDU; de lo contrario, se requiere UINT16 (ECU Configuration p. 153).

De forma análoga, PduLengthType se define en función de la configuración como uint8, uint16 o uint32. El factor determinante es la longitud máxima de las PDU que transmite una unidad de control ([SWS_COMTYPE_00008]). Los protocolos de transporte también derivan las longitudes a partir de EcuC: CanTp determina la longitud máxima de transmisión de la N-PDU a partir del parámetro de EcuC PduLength (SWS CanTp p. 60).

Las API de la pila combinan dos elementos: un puntero al búfer de datos de la PDU y un ID de handle que determina a qué PDU pertenece dicho puntero. El módulo proveedor selecciona libremente el valor del ID de handle. De este modo, la misma PDU puede enviarse desde Com con ID 5 al PduR y desde el PduR con ID 19 a CanIf. El ID solo debe ser unívoco dentro del ámbito de validez de la API correspondiente (ECU Configuration p. 156). Para que dos módulos puedan referenciar la misma PDU, en la configuración virtual de módulos EcuC existe la EcucPduCollection independiente de los módulos (ECU Configuration p. 154). El PduR identifica una ruta de enrutamiento mediante el ID de origen y los ID de destino, traduce los ID y reenvía el valor de PduInfoType sin modificar (SWS PduR p. 33).

Diagrama de colaboración: cada interfaz tiene sus propios ID de handle; el PduR los traduce, mientras que la PDU común se referencia a través de EcucPduCollection. Fuentes: ECU Configuration p. 156, ECU Configuration p. 154, SWS PduR p. 33

PduInfoType: datos útiles, metadatos y longitud en una estructura

PduInfoType agrupa tres elementos ([SWS_COMTYPE_00011]):

• SduDataPtr apunta a los datos útiles.
• MetaDataPtr apunta a metadatos como el ID de CAN, el ID de socket o direcciones de diagnóstico. Su longitud y tipo se configuran estáticamente para cada PDU; los elementos de más de 8 bits se encuentran en el orden de bytes de la plataforma.
• SduLength de tipo PduLengthType indica la longitud de la SDU en bytes.

La misma estructura soporta varias formas de interacción:

• Solicitud de transmisión: <Mod>_Transmit(TxPduId, const PduInfoType*) transfiere la longitud, el puntero de datos y el puntero de metadatos, y devuelve E_OK o E_NOT_OK (SWS CanIf p. 87).
• Indicación de recepción: <Mod>_RxIndication(RxPduId, const PduInfoType*). En CanNm, el puntero de datos solo es válido hasta el retorno de la indicación (SWS CanNm p. 73).
• Trigger Transmit: PduInfoPtr es de entrada y salida. En la invocación, SduLength contiene el tamaño de búfer disponible; al retornar, la longitud de los datos copiados (SWS CanIf p. 107). En la solicitud de transmisión previa, la capa superior solo transfiere la longitud; en ese caso, SduDataPtr apunta a NULL (SWS CanIf p. 158).
• Interfaces de copia de TP: StartOfReception, CopyRxData y CopyTxData con valor de retorno BufReq_ReturnType (SWS PduR p. 93).

Búfer del protocolo de transporte: copia por segmentos en lugar de transferencia completa

Las PDU grandes no se transfieren como un bloque completo. El emisor recupera los datos por fragmentos: DCM inicia CanTp_Transmit a través del PduR. A continuación, CanTp invoca repetidamente PduR_CanTpCopyTxData, que se reenvía a Dcm_CopyTxData. Al final se encuentran PduR_CanTpTxConfirmation y Dcm_TpTxConfirmation (SWS PduR p. 109). Para los parámetros de CopyTxData aplica lo siguiente:

• info suministra el búfer de destino y la cantidad de bytes que se van a copiar.
• Un SduLength de 0 solo notifica un cambio de estado en el parámetro retry o consulta la cantidad de datos disponible; en tal caso, SduDataPtr puede ser NULL_PTR (SWS PduR p. 93).
• availableDataPtr notifica los datos de transmisión restantes. Los módulos TP con longitud de carga útil dinámica, como FrIsoTp, determinan en función de esto los Consecutive Frames siguientes (SWS LdCom p. 34).

Diagrama de secuencia: en la transmisión por TP, el protocolo de transporte extrae los datos de la capa superior en un bucle a través del PduR; la confirmación sigue únicamente tras el último segmento. Fuentes: SWS PduR p. 109, SWS PduR p. 93, [SWS_COMTYPE_00012]

La recepción transcurre en tres pasos:

1. StartOfReception abre la conexión. info contiene los datos del First o Single Frame junto con los metadatos, o bien es NULL_PTR si no está presente ninguno de los dos. TpSduLength indica la longitud total. Mediante bufferSizePtr, el receptor notifica su búfer libre; a partir de ello, el protocolo de transporte calcula el Block Size (SWS PduR p. 92).
2. Cada invocación de CopyRxData entrega el fragmento siguiente de la I-PDU y vuelve a escribir el búfer restante (SWS PduR p. 91).
3. Una RxIndication concluye la recepción.

Si además se realiza una función de pasarela con una PDU de TP, el propio PduR la almacena en búfer, ya que el DCM no tiene constancia de la pasarela (SWS PduR p. 112).

Diagrama de secuencia: la recepción por TP comienza con una negociación de búfer, continúa por segmentos y finaliza con la indicación. Fuentes: SWS PduR p. 112, SWS PduR p. 92, SWS PduR p. 91

Confirmación y reintento: RetryInfoType y TpDataStateType

RetryInfoType contiene dos campos ([SWS_COMTYPE_00037]):

• TpDataState describe el estado del búfer de TP.
• TxTpDataCnt indica el desplazamiento a partir de la posición actual, el cual determina la cantidad de bytes que se deben retransmitir.

TpDataStateType admite tres valores ([SWS_COMTYPE_00027]):

• TP_DATACONF: todos los datos copiados hasta el momento están confirmados y pueden eliminarse del búfer de TP. Los datos copiados en esta invocación quedan excluidos de ello.
• TP_DATARETRY: los datos ya copiados se vuelven a copiar para subsanar un error. TxTpDataCnt indica el desplazamiento inicial.
• TP_CONFPENDING: los datos copiados hasta el momento deben permanecer en el búfer de TP para la subsanación de errores.

Si el propio retry es NULL_PTR, los datos pueden liberarse inmediatamente después de la copia (SWS PduR p. 93).

Diagrama de actividad: una invocación de CopyTxData evalúa en primer lugar el parámetro retry y, a continuación, decide si copiar o devolver BUFREQ_E_BUSY. Fuentes: SWS PduR p. 93, [SWS_COMTYPE_00027], [SWS_COMTYPE_00012]

El diagrama correspondiente al protocolo de transporte J1939 muestra la interacción de forma concreta:

• Para cada bloque, el primer paquete se solicita con TP_DATACONF, y los siguientes con TP_CONFPENDING.
• Si se pierde un TP.DT, la transferencia se reinicia en el primer paquete del bloque. Para ello se establece TP_DATARETRY, y TxTpDataCnt contiene el desplazamiento hacia el inicio del bloque (SWS J1939Tp p. 55).

No todos los usuarios evalúan el parámetro: según la especificación, en LdCom retry no es gestionado ni por LdCom ni por su capa superior (SWS LdCom p. 34).

Diagrama de secuencia: transferencia por bloques con estados de confirmación y retorno al inicio del bloque en caso de pérdida de un paquete de datos. Fuentes: SWS J1939Tp p. 55, [SWS_COMTYPE_00027], [SWS_COMTYPE_00037]

Canales, subredes y parámetros de TP

NetworkHandleType es un uint8 con el rango 0..255 basado en cero. Almacena el identificador de un canal de comunicación ([SWS_COMTYPE_00038]). Ejemplos de versiones posteriores:

• Bus Mirroring notifica una trama LIN con el canal de ComM asignado al canal de LIN (SWS Mirror p. 80).
• J1939Dcm transfiere el canal en el que se recibió una solicitud (SWS J1939Dcm p. 67).

PNCHandleType almacena el identificador de un Partial Network Cluster y en R20-11 se deriva de uint8 ([SWS_COMTYPE_00036]). En cambio, el pasaje del documento de R23-11 menciona uint16 (SWS ComStackTypes p. 17). Para R20-11 aplica el requisito. El contexto de aplicación de los identificadores de PNC lo muestra, por ejemplo, la desconexión sincronizada de PNC en el ComM (SWS ComM p. 171).

TPParameterType designa el parámetro del protocolo de transporte cuyo valor se va a modificar ([SWS_COMTYPE_00031]):

• TP_STMIN: Separation Time,
• TP_BS: Block Size,
• TP_BC: control de ancho de banda del protocolo de transporte de FlexRay.

Block Size y STmin aparecen, por ejemplo, en la trama de control de flujo del protocolo de transporte AR de FlexRay (SWS FrArTp p. 47).

Comportamiento en caso de error

BufReq_ReturnType describe el resultado de una solicitud de búfer ([SWS_COMTYPE_00012]):

• BUFREQ_OK (0): correcto.
• BUFREQ_E_NOT_OK (1): el búfer no es accesible.
• BUFREQ_E_BUSY (2): temporalmente no hay ningún búfer disponible; el solicitante debe reintentarlo durante un tiempo determinado.
• BUFREQ_E_OVFL (3): no es posible suministrar ningún búfer con la longitud requerida.

Las interfaces asignan estos valores del siguiente modo:

• CopyTxData: si los datos de transmisión no son suficientes, no se copia nada y se devuelve BUFREQ_E_BUSY; la capa inferior puede repetir la llamada (SWS PduR p. 93). En la secuencia de búfer paginado del DCM, BUFREQ_E_BUSY se presenta de forma alterna con la preparación de la página siguiente (SWS DCM p. 481).
• StartOfReception: BUFREQ_E_NOT_OK rechaza la conexión e interrumpe la recepción; bufferSizePtr permanece sin cambios. BUFREQ_E_OVFL aborta la operación debido a que no hay disponible ningún búfer con la longitud necesaria. Con BUFREQ_OK sin un búfer del tamaño solicitado, se notifica un tamaño de búfer de 0 (SWS DCM p. 273).
• CopyRxData: BUFREQ_E_NOT_OK significa que no se ha copiado nada debido a un error (SWS PduR p. 91).
• Error de transmisión en TP: la subsanación se realiza mediante TP_DATARETRY con el desplazamiento TxTpDataCnt ([SWS_COMTYPE_00027]).
• TriggerTransmit: E_NOT_OK significa que no se ha copiado nada. En tal caso, PduInfoPtr no debe utilizarse, ya que puede ser NULL o no válido (SWS CanIf p. 107).

Los módulos usuarios definen por sí mismos comprobaciones adicionales. Ejemplos:

• DoIP_SoAdTpCopyRxData comprueba, con la detección de errores de desarrollo activada, si DoIP_Init ha sido invocado previamente (SWS DoIP p. 77).
• FrIf_Transmit devuelve el valor E_NOT_OK en el estado FRIF_STATE_OFFLINE (SWS FrIf p. 68).
• Muchas de estas funciones solo son reentrantes para ID de PDU diferentes, no para el mismo (SWS DoIP p. 75).

Más evidencia detallada

La siguiente vista general clasifica las referencias más importantes ([SWS_COMTYPE_00005] a [SWS_COMTYPE_00038]):

Referencia	Clasificación
[SWS_COMTYPE_00005], [SWS_COMTYPE_00008]	Anchura dependiente de la configuración de PduIdType y PduLengthType, generada a partir de EcuC
[SWS_COMTYPE_00011]	Estructura de PduInfoType incluidos los metadatos
[SWS_COMTYPE_00012]	Códigos de resultado de todas las solicitudes de búfer de TP
[SWS_COMTYPE_00027], [SWS_COMTYPE_00037]	Lógica de confirmación y reintento en la transmisión por TP
[SWS_COMTYPE_00031], [SWS_COMTYPE_00036], [SWS_COMTYPE_00038]	Selección de parámetros de TP, identificadores de PNC y de canal
ECU Configuration S. 156	Concepto de ID de handle: valores libremente seleccionables por módulo, unívocos por API
SWS PduR S. 93, SWS PduR S. 92	Semántica de referencia de las interfaces de copia de TP
SWS J1939Tp S. 55	Diagrama para el tratamiento de reintentos (indicado también para R20-11)