AUTOSAR COM

Uso y semántica

La función Com_Init inicializa las interfaces internas y externas, así como las variables de la capa AUTOSAR COM para el procesamiento posterior ([SWS_Com_00432]). La llamada se realiza de forma síncrona y no es reentrante (Non Reentrant) ([SWS_Com_00432]). Como parámetro de transferencia, config sirve como puntero a los datos de configuración del módulo COM (const Com_ConfigType* config); no existe ningún valor de retorno ([SWS_Com_00432]). En configuraciones multipartición en las que las funciones principales del módulo COM están asignadas a varias particiones, COM puede proporcionar una función de inicialización propia por cada partición ([SWS_Com_00432]).

Condiciones de orden secuencial y tratamiento de errores

La inicialización mediante Com_Init es el requisito previo funcional para el uso regular de las interfaces COM: si se llama a un servicio API antes de Com_Init o después de una llamada a Com_DeInit, se genera el código de error COM_E_UNINIT (0x02) ([SWS_Com_00804]). Quedan excluidas de esta comprobación de errores exclusivamente las llamadas a Com_GetStatus, Com_GetVersionInfo, Com_MainFunctionRx, Com_MainFunctionTx y Com_MainFunctionRouteSignals ([SWS_Com_00804]).

Interacción en la inicialización de PDU y señales

Tras la ejecución de Com_Init, la comunicación inter-ECU propiamente dicha permanece inicialmente desactivada ([SWS_Com_00432]). Interpretación: para el funcionamiento regular de envío y recepción, probablemente sea necesaria una activación posterior de los respectivos grupos de I-PDU. Pregunta Q-8407f9a6281c3764 (abierta) Sin embargo, para determinadas estructuras de datos, Com_Init ya realiza inicializaciones directas:

• Si una I-PDU no está asignada a ningún grupo de I-PDU, COM ya inicia esta I-PDU dentro de Com_Init tal como si se hubiera iniciado mediante Com_IpduGroupStart con el parámetro de inicialización establecido ([SWS_Com_00840]).
• Para grupos de señales con acceso de arreglo configurado (ComSignalGroupArrayAccess), Com_Init inicializa el área de búfer correspondiente de la I-PDU en función de los valores iniciales (ComSignalInitValue) de todas las señales de grupo contenidas ([SWS_Com_00850]).

Uso y contexto de llamada

La función síncrona [SWS_Com_00130] (interpretación: indicada en el payload como 'Init', pero especifica la firma void Com_DeInit(void)) finaliza la comunicación inter-ECU y pone el módulo AUTOSAR COM en el estado no inicializado ([SWS_Com_00130]). Pregunta Q-3e91d7d0a140cee0 (abierta) El servicio posee el ID de servicio 0x02, no requiere parámetros de transferencia, no devuelve ningún valor de retorno y se proporciona a través del archivo de cabecera Com.h ([SWS_Com_00130]).

Concurrencia y restricciones

En cuanto al contexto de llamada, la función está definida como no reentrante (Non Reentrant) ([SWS_Com_00130]). Por lo tanto, una llamada paralela o múltiple sin reinicialización previa no está permitida.

Zusammenspiel y ciclo de vida

Mediante la desinicialización se detienen todos los grupos de I-PDU iniciados previamente ([SWS_Com_00130]). Para una reanudación posterior de la comunicación se aplican las siguientes condiciones de orden:

• El módulo debe reinicializarse mediante el servicio síncrono y no reentrante Com_Init pasando el puntero de configuración config ([SWS_Com_00432]).
• Dado que la comunicación inter-ECU permanece desactivada tras la llamada a Com_Init ([SWS_Com_00432]), los grupos de I-PDU requeridos deben iniciarse explícitamente de nuevo a continuación ([SWS_Com_00130]).

La función síncrona Com_IpduGroupStart (ID de servicio 0x03, cabecera Com.h) sirve para iniciar un grupo de I-PDU preconfigurado [SWS_Com_91001]. Tras la llamada, se activa la transmisión de las I-PDUs correspondientes; por ejemplo, las I-PDUs periódicas se enviarán periódicamente a partir de ese momento [SWS_Com_91001].

Uso y parámetros

La función no tiene valor de retorno y recibe dos parámetros de entrada [SWS_Com_91001]:

• IpduGroupId: identificador unívoco del grupo de I-PDU preconfigurado que se va a iniciar [SWS_Com_91001].
• initialize: un indicador booleano para solicitar la inicialización de datos de las I-PDUs de este grupo antes del inicio [SWS_Com_91001].

Si initialize está establecido en true, todas las I-PDUs del grupo deben (re)inicializarse antes del inicio [SWS_Com_91001]. A continuación, las I-PDUs se comportan igual que inmediatamente después de un arranque del módulo COM [SWS_Com_91001]. Esto incluye, en particular, la reinicialización del valor anterior (old_value) de los objetos de filtro, así como de los búferes sombra para grupos de señales [SWS_Com_91001].

Concurrencia y restricciones

En cuanto a la concurrencia, Com_IpduGroupStart es reentrante para diferentes grupos de I-PDU, pero explícitamente no reentrante para el mismo grupo de I-PDU [SWS_Com_91001].

usar

La función Com_IpduGroupStop sirve para detener un grupo de I-PDU preconfigurado en el módulo AUTOSAR COM [SWS_Com_91002]. La declaración está disponible a través del archivo de cabecera Com.h y tiene el ID de servicio 0x04 [SWS_Com_91002].

• Sintaxis de invocación: void Com_IpduGroupStop (Com_IpduGroupIdType IpduGroupId) [SWS_Com_91002].
• Parámetros: como único parámetro se pasa el parámetro de entrada IpduGroupId del tipo Com_IpduGroupIdType, que determina el identificador del grupo de I-PDU que se va a detener [SWS_Com_91002]. No existen parámetros adicionales de entrada/salida (inout) ni de salida (out) [SWS_Com_91002].
• Valor de retorno: La interfaz no devuelve ningún valor de retorno (void) [SWS_Com_91002].
• Comportamiento de ejecución: la llamada se procesa de forma síncrona [SWS_Com_91002]. Tras la llamada a Com_IpduGroupStop, se detiene la comunicación del grupo afectado; esto provoca, por ejemplo, que las I-PDUs periódicas del grupo dejen de enviarse [SWS_Com_91002].

Concurrencia y restricciones

En relación con la concurrencia y la reentrancia, se establece que Com_IpduGroupStop es reentrante para diferentes grupos de I-PDU, pero no debe ejecutarse de forma reentrante para el mismo grupo de I-PDU [SWS_Com_91002]. Si la función se invoca en entornos multitarea o multinúcleo, el software llamador debe garantizar que se excluyan llamadas simultáneas para un mismo ID de grupo.

La función síncrona Com_EnableReceptionDM sirve para activar la supervisión de plazos de recepción (Reception Deadline Monitoring) para todas las I-PDUs dentro de un grupo de I-PDU predeterminado [SWS_Com_91004].

Uso y contexto de invocación: la función está declarada a través del archivo de cabecera Com.h y tiene el ID de servicio 0x06 [SWS_Com_91004]. Como único parámetro de transferencia, la firma void Com_EnableReceptionDM (Com_IpduGroupIdType IpduGroupId) espera el parámetro de entrada IpduGroupId del tipo Com_IpduGroupIdType, que representa el identificador del grupo de I-PDU para cuyas I-PDUs contenidas debe activarse la supervisión de plazos [SWS_Com_91004]. La ejecución se realiza de forma síncrona [SWS_Com_91004]. No existen parámetros de entrada/salida ni de salida, y no se devuelve ningún valor de retorno (tipo de retorno void) [SWS_Com_91004].

Concurrencia y restricciones: en relación con la concurrencia, Com_EnableReceptionDM es reentrante para diferentes grupos de I-PDU, pero no es reentrante para el mismo grupo de I-PDU [SWS_Com_91004]. Por lo tanto, no se permiten llamadas concurrentes para el mismo ID de grupo y deben evitarse en el contexto de invocación [SWS_Com_91004].

La función síncrona Com_DisableReceptionDM desactiva la supervisión de plazos de recepción (Reception Deadline Monitoring) para todas las I-PDUs dentro del grupo de I-PDU pasado [SWS_Com_91003].

usar

La llamada se realiza a través de la interfaz void Com_DisableReceptionDM(Com_IpduGroupIdType IpduGroupId) con el identificador del grupo de I-PDU afectado como parámetro de entrada IpduGroupId [SWS_Com_91003]. La función no tiene parámetros de entrada/salida ni de salida, y no devuelve ningún valor de retorno (void) [SWS_Com_91003]. El servicio está declarado con el ID de servicio 0x05 en el archivo de cabecera Com.h [SWS_Com_91003].

Concurrencia y restricciones

En cuanto al comportamiento de concurrencia, el servicio es reentrante para diferentes grupos de I-PDU, pero no debe llamarse de forma concurrente (no reentrante) para el mismo grupo de I-PDU [SWS_Com_91003].

La función Com_SendSignal sirve para actualizar un objeto de señal identificado mediante SignalId con los datos a los que apunta el puntero SignalDataPtr [SWS_Com_00197]. La llamada se procesa de forma asíncrona [SWS_Com_00197].

Valores de retorno y tratamiento de errores

La función devuelve un estado de tipo uint8 [SWS_Com_00197]:

• E_OK: el servicio ha sido aceptado [SWS_Com_00197].
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU asociado se ha detenido o la llamada ha fallado debido a un error de desarrollo [SWS_Com_00197].
• COM_BUSY: se produce cuando el búfer de TP está bloqueado para el procesamiento de tipos de datos grandes [SWS_Com_00197].

Concurrencia y restricciones

En cuanto a la reentrancia, Com_SendSignal no es reentrante para la misma señal, pero se puede invocar de forma concurrente para diferentes señales [SWS_Com_00197]. La interfaz se proporciona a través de la cabecera Com.h [SWS_Com_00197].

Interacción y configuración

Si para un grupo de señales se ha definido la configuración ComSignalGroupArrayAccess, la llamada a Com_SendSignal no está soportada para las señales de grupo de dicho grupo de señales [SWS_Com_00843].

La función Classic AUTOSAR Com_SendDynSignal sirve para actualizar un objeto de señal con longitud dinámica a partir de los datos útiles pasados ([SWS_Com_00627]). El servicio tiene el ID de servicio 0x21 y funciona de forma asíncrona ([SWS_Com_00627]). Como parámetros de entrada, la interfaz espera el identificador de la señal de destino (SignalId), un puntero a los datos útiles de la señal que se van a transmitir (SignalDataPtr), así como la longitud actual de la señal dinámica (Length); no existen parámetros de salida ([SWS_Com_00627]).

El valor de retorno del tipo uint8 notifica el resultado de la aceptación de la solicitud ([SWS_Com_00627]):

• E_OK: La llamada al servicio se aceptó correctamente ([SWS_Com_00627]).
• E_NOT_OK: el parámetro Length supera la longitud máxima configurada para esta señal ComSignalLength ([SWS_Com_00627]).
• COM_SERVICE_NOT_AVAILABLE: El grupo de I-PDU asociado está detenido o el servicio falló debido a un error de desarrollo ([SWS_Com_00627]).
• COM_BUSY: el búfer TP está bloqueado ([SWS_Com_00627]).

En cuanto a la concurrencia, Com_SendDynSignal es reentrante para diferentes señales, pero no es reentrante para la misma señal ([SWS_Com_00627]). La declaración de la función está disponible a través del encabezado Com.h ([SWS_Com_00627]).

La función síncrona Com_ReceiveSignal copia los datos de la señal especificada a través de SignalId a la dirección de memoria proporcionada a través del puntero SignalDataPtr ([SWS_Com_00198]).

Uso y semántica

La llamada procesa la transferencia de señal de forma síncrona y acepta como parámetro de entrada el identificador SignalId (de tipo Com_SignalIdType) así como, en calidad de parámetro de salida, el puntero SignalDataPtr (void*) al búfer de destino ([SWS_Com_00198]). La interfaz está disponible a través del encabezado Com.h ([SWS_Com_00198]).

Valores de retorno y tratamiento de errores

El valor de retorno de tipo uint8 señala el resultado de la ejecución de la función ([SWS_Com_00198]):

• E_OK: el servicio se aceptó y ejecutó con éxito ([SWS_Com_00198]).
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU correspondiente se detuvo o el servicio falló a causa de un error de desarrollo ([SWS_Com_00198]).
• COM_BUSY: ocurre si el búfer TP está bloqueado para el procesamiento de tipos de datos grandes ([SWS_Com_00198]).

Concurrencia y restricciones

En cuanto a la reentrancia, Com_ReceiveSignal no es reentrante para la misma señal, pero sí es reentrante para señales diferentes ([SWS_Com_00198]). En caso de accesos paralelos a ID de señal idénticos, los llamadores deben garantizar, por consiguiente, una sincronización adecuada.

Además, existe una restricción de configuración esencial: si para un grupo de señales está configurado el acceso basado en arreglos ComSignalGroupArrayAccess, no se admite la llamada a Com_ReceiveSignal para las señales de grupo contenidas de dicho grupo de señales ([SWS_Com_00843]).

Uso y semántica

La función síncrona Com_ReceiveDynSignal sirve para la recepción de una señal con longitud dinámica a partir de su SignalId [SWS_Com_00690]. Los datos de señal recibidos se copian en la ubicación de memoria a la que apunta SignalDataPtr [SWS_Com_00690]. A través del parámetro de entrada/salida (in-out) Length, el invocador pasa como valor de entrada la longitud máxima admisible; tras completarse con éxito la operación de copia, se almacena allí la longitud real de la señal dinámica recibida [SWS_Com_00690].

Valores de retorno y tratamiento de errores

La función devuelve un valor de estado de tipo uint8 [SWS_Com_00690]:

• E_OK: la llamada al servicio ha sido aceptada y los datos se han copiado correctamente [SWS_Com_00690].
• E_NOT_OK: el búfer proporcionado es demasiado pequeño, ya que el valor de entrada de Length es menor que la longitud real de la señal recibida [SWS_Com_00690].
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU correspondiente se detuvo o el servicio falló a causa de un error de desarrollo [SWS_Com_00690].
• COM_BUSY: el búfer TP está bloqueado actualmente [SWS_Com_00690].

Concurrencia e integración

En cuanto a la reentrancia, Com_ReceiveDynSignal no es reentrante para la misma señal, pero se puede llamar de forma reentrante para diferentes señales [SWS_Com_00690]. La declaración está disponible a través de Com.h [SWS_Com_00690].

La función asíncrona Com_SendSignalGroup sirve para copiar el contenido del búfer sombra asignado en la I-PDU correspondiente [SWS_Com_00200]. Como parámetro de entrada, acepta el identificador SignalGroupId del grupo de señales que se va a transmitir [SWS_Com_00200].

Valores de retorno y tratamiento de errores

El valor de retorno señala el estado de ejecución del servicio [SWS_Com_00200]:

• E_OK: La llamada al servicio se aceptó correctamente [SWS_Com_00200].
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU correspondiente se detuvo o el servicio falló a causa de un error de desarrollo [SWS_Com_00200].
• COM_BUSY: el búfer TP está bloqueado temporalmente para la transmisión de tipos de datos grandes [SWS_Com_00200].

Concurrencia y restricciones

En cuanto a la concurrencia, la llamada no es reentrante para la misma señal de grupo, pero sí reentrante para diferentes señales de grupo [SWS_Com_00200]. Interpretación: es probable que la restricción se refiera a accesos simultáneos al mismo grupo de señales. Pregunta Q-2f3a6da092b51794 (abierta) Además, la llamada a Com_SendSignalGroup para un grupo de señales no es compatible si se configuró ComSignalGroupArrayAccess para este [SWS_Com_00843].

Interacción

El módulo AUTOSAR COM trata una llamada a Com_SendSignalGroupArray de forma equivalente a Com_SendSignalGroup en lo relativo a las propiedades de transmisión, la selección del modo de transmisión de la I-PDU y el flujo de señal [SWS_Com_00847].

usar

La función síncrona Com_ReceiveSignalGroup sirve para la recepción de grupos de señales. Copia los datos del grupo de señales recibido desde la I-PDU correspondiente al búfer sombra (shadow buffer) asignado [SWS_Com_00201]. Como parámetro de entrada, la función espera el identificador del grupo de señales SignalGroupId de tipo Com_SignalGroupIdType [SWS_Com_00201]. El servicio está declarado en el archivo de cabecera Com.h [SWS_Com_00201].

Tratamiento de errores y valores de retorno

El servicio devuelve un valor de estado de tipo uint8 que informa sobre el éxito o la causa del error [SWS_Com_00201]:

• E_OK: el servicio se aceptó con éxito y el grupo de señales se copió [SWS_Com_00201].
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU asociado se ha detenido o la llamada ha fallado debido a un error de desarrollo [SWS_Com_00201].
• COM_BUSY: el servicio notifica este estado si el búfer TP está bloqueado para la gestión de tipos de datos grandes [SWS_Com_00201].

Concurrencia y restricciones

En cuanto al comportamiento de concurrencia, Com_ReceiveSignalGroup está implementada como no reentrante para el mismo grupo de señales, pero reentrante para diferentes grupos de señales [SWS_Com_00201].

Además, existe una restricción esencial en la interacción con el acceso por arrays: si para un grupo de señales se ha definido la configuración ComSignalGroupArrayAccess (ECUC_Com_10003), la llamada a Com_ReceiveSignalGroup para este grupo de señales no está soportada según la especificación [SWS_Com_00843].

La función asíncrona Com_SendSignalGroupArray copia los datos de un grupo de señales a través del puntero SignalGroupArrayPtr directamente en la I-PDU asignada [SWS_Com_00851]. Los datos pasados deben corresponder exactamente a la representación en array del grupo de señales correspondiente [SWS_Com_00851], [SWS_Com_00852].

Como parámetros de entrada se pasan el identificador del grupo de señales (SignalGroupId), así como la referencia al array del grupo de señales (SignalGroupArrayPtr) [SWS_Com_00851]. El servicio proporciona los siguientes valores de retorno [SWS_Com_00851]:

• E_OK: La llamada al servicio se aceptó correctamente.
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU correspondiente se ha detenido o la llamada ha fallado debido a un error de desarrollo.
• COM_BUSY: el búfer del protocolo de transporte (búfer TP) está bloqueado para el procesamiento de tipos de datos grandes.

En cuanto a la concurrencia, la función no es reentrante para el mismo grupo de señales, pero puede llamarse de forma reentrante para diferentes grupos de señales [SWS_Com_00851]. La llamada solo está disponible si el interruptor de configuración ComEnableSignalGroupArrayApi está activado [SWS_Com_00853].

Con respecto a las propiedades de transmisión de grupos de señales, a la selección del modo de transmisión de I-PDU y al flujo de señales, el módulo AUTOSAR COM trata a Com_SendSignalGroupArray de forma totalmente análoga a Com_SendSignalGroup [SWS_Com_00847].

Uso y configuración

La función síncrona Com_ReceiveSignalGroupArray copia el grupo de señales recibido como representación de array de bytes desde la I-PDU al área de memoria a la que apunta SignalGroupArrayPtr [SWS_Com_00854], [SWS_Com_00855]. La función está disponible exclusivamente si el interruptor de configuración ComEnableSignalGroupArrayApi está activado [SWS_Com_00856]. Admite el filtrado de recepción y la Transmission Mode Selection con los filtros ALWAYS, NEVER, MASKED_NEW_EQUALS_X, MASKED_NEW_DIFFERS_X, MASKED_NEW_DIFFERS_MASKED_OLD y ONE_EVERY_N [SWS_Com_00848].

Copia de datos y tratamiento de errores

En la llamada se pasa el SignalGroupId, así como un puntero al array de destino en cuya posición el módulo AUTOSAR COM copia los datos de la I-PDU [SWS_Com_00849]. Incluso si el grupo de I-PDU está detenido y el servicio devuelve COM_SERVICE_NOT_AVAILABLE, el módulo copia siempre los últimos datos conocidos o los valores iniciales ComSignalInitValues si aún no se han escrito datos con anterioridad [SWS_Com_00857].

Valores de retorno y concurrencia

Los posibles valores de retorno del servicio son [SWS_Com_00854]:

• E_OK: El servicio se aceptó correctamente.
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU correspondiente está detenido o el servicio ha fallado debido a un error de desarrollo.
• COM_BUSY: El búfer de TP está bloqueado para el procesamiento de tipos de datos grandes.

En cuanto a la concurrencia, la función es reentrante para diferentes grupos de señales, pero no es reentrante para el mismo grupo de señales [SWS_Com_00854].

La función síncrona Com_ReceiveSignalWithMetaData sirve para leer datos de señal recibidos junto con sus metadatos desde el módulo de comunicación Com [SWS_Com_91005]. Al invocarse, el servicio copia los datos de la señal direccionada a través de la SignalId en la ubicación de memoria a la que apunta SignalDataPtr y almacena los metadatos recibidos en la posición MetaDataPtr [SWS_Com_91005].

Parámetros y contexto de llamada

La interfaz está disponible a través de la cabecera Com.h y se identifica mediante el Service-ID 0x49 [SWS_Com_91005]. La estructura de parámetros se divide de la siguiente manera:

• SignalId (in): identificador de la señal que se va a recibir [SWS_Com_91005].
• SignalDataPtr (out): puntero a la ubicación de memoria para almacenar los datos de señal recibidos [SWS_Com_91005].
• MetaDataPtr (out): puntero a la zona de memoria para recibir los metadatos de la señal [SWS_Com_91005].

La función devuelve un valor de retorno del tipo uint8, para el cual no se han documentado valores de error específicos en la presente sección del estándar [SWS_Com_91005].

Concurrencia y restricciones

En cuanto a la reentrancia, el servicio es reentrante para señales diferentes, pero no es reentrante para la misma señal [SWS_Com_91005]. En caso de llamadas paralelas o que provoquen interrupción con idéntica SignalId, probablemente sea necesaria una protección externa por parte del llamador para garantizar la coherencia de los datos. Pregunta Q-51cbdce3d4f59f24 (abierta)

Uso y semántica

La función Com_ReceiveDynSignalWithMetaData se proporciona a través del archivo de cabecera Com.h y sirve para la recepción síncrona de señales con longitud dinámica, incluidos sus metadatos [SWS_Com_91006]. Al invocarse, el servicio copia los datos de la señal identificada mediante SignalId en el búfer referenciado por SignalDataPtr [SWS_Com_91006]. Los metadatos recibidos se almacenan en el puntero MetaDataPtr, mientras que la longitud real de la señal dinámica recibida se escribe en la posición de Length [SWS_Com_91006].

Valores de retorno y tratamiento de errores

El servicio devuelve un valor de estado del tipo uint8 [SWS_Com_91006]:

• E_OK: el servicio de recepción se ha aceptado correctamente [SWS_Com_91006].
• E_NOT_OK: se produce cuando el valor pasado de Length es menor que la longitud real de la señal dinámica recibida [SWS_Com_91006]. Interpretación: la entidad invocadora debe suministrar previamente el tamaño del búfer a través de Length, de modo que el parámetro actúa de facto como entrada y salida combinadas. Pregunta Q-8ad420c74748f219 (abierta)
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU asociado está detenido o la llamada ha fallado debido a un error de desarrollo [SWS_Com_91006].
• COM_BUSY: el búfer TP está bloqueado actualmente [SWS_Com_91006].

Concurrencia y restricciones

En cuanto a la concurrencia, la función es reentrante para diferentes señales, pero no se debe llamar de forma reentrante para la misma señal [SWS_Com_91006]. Por tanto, las llamadas paralelas para el mismo SignalId deben sincronizarse en el nivel del invocador.

La función síncrona Com_ReceiveSignalGroupWithMetaData sirve para la recepción de un grupo de señales, incluidos los metadatos correspondientes, a través de la interfaz Com.h [SWS_Com_91007]. Toma como parámetro de entrada el identificador SignalGroupId y copia los datos recibidos del grupo de señales desde la I-PDU hacia el shadow buffer local [SWS_Com_91007]. Al mismo tiempo, el servicio almacena los metadatos recibidos en la dirección de destino referenciada a través del parámetro de salida MetaDataPtr [SWS_Com_91007].

El comportamiento de retorno y de error comprende tres valores de estado: E_OK señaliza la aceptación correcta del servicio [SWS_Com_91007]. El valor de retorno COM_SERVICE_NOT_AVAILABLE indica que el grupo de I-PDU correspondiente está detenido o que existe un error de desarrollo [SWS_Com_91007]. Si se produce el código de error COM_BUSY, el búfer TP está bloqueado para el procesamiento de tipos de datos grandes [SWS_Com_91007]. En cuanto a la concurrencia, la función es reentrante para diferentes grupos de señales, pero no reentrante para el mismo grupo de señales [SWS_Com_91007]. Dado que la especificación no menciona restricciones relativas a ISR, es de suponer que la llamada la realice el componente de software superior de forma síncrona a nivel de tarea. Pregunta Q-a23cf67bae724ae1 (abierta)

En su interacción, la función amplía la ruta de recepción con metadatos de forma análoga a Com_ReceiveSignalWithMetaData para señales individuales [SWS_Com_91005]. Los metadatos proporcionados se corresponden con la información de PDU recibida previamente en la interfaz a través de Com_RxIndication [SWS_Com_00123]. Además, para señalizar contenidos de datos no válidos en el flujo global se puede recurrir a Com_InvalidateSignalGroup [SWS_Com_00557].

usar

El servicio síncrono Com_ReceiveSignalGroupArrayWithMetaData (ID de servicio 0x4c, disponible a través de Com.h) copia la representación en array del grupo de señales recibido desde la I-PDU hacia la ubicación de memoria proporcionada a través del puntero SignalGroupArrayPtr [SWS_Com_91008]. Al mismo tiempo, los metadatos recibidos se escriben en la posición indicada por el parámetro MetaDataPtr [SWS_Com_91008]. La función no tiene valor de retorno (void) [SWS_Com_91008].

Manejo de errores

La especificación no define valores de retorno para este servicio ni lista códigos de error específicos [SWS_Com_91008]. Interpretación: es de suponer que cualquier condición de error en los parámetros de llamada se capture internamente y se gestione a través del reporte de errores del módulo; no obstante, del extracto de la especificación no se desprenden avisos concretos a DET o DEM. Pregunta (abierta)

Concurrencia y restricciones

En cuanto a la concurrencia, la función es reentrante para diferentes grupos de señales, pero no es reentrante para el mismo grupo de señales [SWS_Com_91008]. Las llamadas paralelas con un SignalGroupId idéntico deben evitarse por parte del invocador. Interpretación: además, se supone que los invocadores están obligados a proporcionar búferes de destino con dimensiones suficientes, ya que la interfaz no incluye parámetros de longitud. Pregunta (abierta)

Interacción

La puesta a disposición de los datos en el búfer de PDU presupone que previamente se haya producido una indicación de recepción a través de Com_RxIndication, la cual también entrega los metadatos al módulo COM [SWS_Com_00123]. La función amplía las interfaces de recepción para metadatos de forma análoga a Com_ReceiveSignalWithMetaData para señales individuales [SWS_Com_91005] y se distingue de la recuperación regular de señales mediante Com_ReceiveSignal [SWS_Com_00198].

La función Com_SendSignalWithMetaData ([SWS_Com_91009]) sirve para actualizar de forma asíncrona un objeto de señal especificado mediante SignalId con datos útiles a través de SignalDataPtr y metadatos asociados a través de MetaDataPtr. El servicio está disponible a través del encabezado Com.h.

• Llamada y concurrencia: la llamada se realiza de forma asíncrona ([SWS_Com_91009]). La función es reentrante para diferentes señales, pero no es reentrante para el mismo identificador de señal (SignalId) ([SWS_Com_91009]).
• Valores de retorno y tratamiento de errores: la función devuelve un valor de estado del tipo uint8 ([SWS_Com_91009]):
  • E_OK: la orden de transmisión ha sido aceptada correctamente por el módulo ([SWS_Com_91009]).
  • COM_SERVICE_NOT_AVAILABLE: El grupo de I-PDU asociado está detenido o la llamada falló debido a un error de desarrollo ([SWS_Com_91009]).
  • COM_BUSY: El búfer de TP está bloqueado para el procesamiento de tipos de datos grandes ([SWS_Com_91009]).
• Interacción: a diferencia del servicio básico de transmisión Com_SendSignal ([SWS_Com_00197]), esta función pasa metadatos explícitos. Constituye la contraparte en el lado de emisión respecto al servicio de recepción Com_ReceiveSignalWithMetaData ([SWS_Com_91005]) y complementa los servicios de metadatos relativos a I-PDU como Com_TriggerIPDUSendWithMetaData ([SWS_Com_00858]).

Uso y semántica

La función Com_SendDynSignalWithMetaData sirve para la actualización asíncrona de un objeto de señal identificado mediante SignalId (tipo Com_SignalIdType) con datos de señal de longitud dinámica así como los metadatos correspondientes [SWS_Com_91010]. Los datos útiles a transmitir se referencian mediante el puntero SignalDataPtr (tipo void*), mientras que MetaDataPtr (tipo uint8*) apunta a los metadatos [SWS_Com_91010]. A través del parámetro Length (tipo uint16) se transfiere la longitud real de la señal dinámica a enviar [SWS_Com_91010].

Valores de retorno y tratamiento de errores

El valor de retorno de tipo uint8 indica si el servicio fue aceptado o qué error se ha producido [SWS_Com_91010]:

• E_OK: La llamada al servicio fue aceptada con éxito para su procesamiento [SWS_Com_91010].
• E_NOT_OK: La Length transferida excede la ComSignalLength configurada para esta señal [SWS_Com_91010].
• COM_SERVICE_NOT_AVAILABLE: El grupo de I-PDU correspondiente fue detenido o la llamada falló debido a un error de desarrollo [SWS_Com_91010].
• COM_BUSY: El búfer de TP está actualmente bloqueado, razón por la cual la señal no puede enviarse [SWS_Com_91010].

Concurrencia e integración

En cuanto a la concurrencia, la función es reentrante para diferentes señales, pero no es reentrante para la misma señal [SWS_Com_91010]. La interfaz posee el Service-ID 0x4e y se pone a disposición en el módulo Com a través del archivo de cabecera Com.h [SWS_Com_91010].

La función Com_SendSignalGroupWithMetaData (denominada en el modelo de datos como Data) sirve para la transmisión asíncrona de un grupo de señales junto con metadatos al módulo Com [SWS_Com_91011]. Al ser llamado, el servicio copia el contenido actual del shadow buffer asignado a la I-PDU correspondiente, proporcionándose los metadatos a través del puntero MetaDataPtr [SWS_Com_91011].

Los parámetros de entrada comprenden el identificador del grupo de señales (SignalGroupId) así como el puntero a los metadatos (MetaDataPtr) [SWS_Com_91011]. Los valores de retorno notifican el resultado de la solicitud del servicio:

• E_OK: El servicio fue aceptado con éxito [SWS_Com_91011].
• COM_SERVICE_NOT_AVAILABLE: El grupo de I-PDU correspondiente fue detenido o la ejecución falló debido a un error de desarrollo [SWS_Com_91011].
• COM_BUSY: El búfer de TP está bloqueado para la transmisión de tipos de datos grandes [SWS_Com_91011].

En cuanto a la concurrencia, la llamada es reentrante para diferentes señales, pero no es reentrante para la misma señal de grupo; de forma análoga al parámetro SignalGroupId, esto probablemente se refiere al grupo de señales respectivo [SWS_Com_91011]. Pregunta Q-91171d77370ae50a (abierta) En interacción con el módulo Com, el servicio complementa el envío de señales individuales como Com_SendSignal [SWS_Com_00197] así como la invalidación de grupos de señales mediante Com_InvalidateSignalGroup [SWS_Com_00557]. Además, se corresponde con el servicio de recepción Com_ReceiveSignalWithMetaData [SWS_Com_91005] y con la llamada de envío basada en PDU Com_TriggerIPDUSendWithMetaData [SWS_Com_00858].

Uso y parámetros

La función Com_SendSignalGroupArrayWithMetaData sirve para la transmisión asíncrona de un grupo de señales junto con los metadatos asociados [SWS_Com_91012]. Al ser llamado, el servicio copia el contenido del puntero transferido SignalGroupArrayPtr directamente a la I-PDU asignada [SWS_Com_91012]. Los datos proporcionados deben corresponder obligatoriamente a la representación en array del grupo de señales, la cual se identifica mediante el parámetro SignalGroupId de tipo Com_SignalGroupIdType [SWS_Com_91012]. Los metadatos adicionales del grupo de señales se transfieren a la capa de comunicación a través del puntero MetaDataPtr [SWS_Com_91012].

Valores de retorno y tratamiento de errores

La función devuelve un valor de estado de tipo uint8 que indica el éxito de la transferencia o la causa de error correspondiente [SWS_Com_91012]:

• E_OK: La llamada al servicio fue aceptada con éxito por la capa COM [SWS_Com_91012].
• COM_SERVICE_NOT_AVAILABLE: el grupo de I-PDU asociado está detenido o la llamada ha fallado debido a un error de desarrollo [SWS_Com_91012].
• COM_BUSY: El búfer del protocolo de transporte (TP buffer) está bloqueado para el procesamiento de tipos de datos grandes [SWS_Com_91012].

Concurrencia y restricciones

Según la especificación, el servicio está clasificado como no reentrante (Non Reentrant), razón por la cual no están permitidas las llamadas simultáneas o que originen interrupciones [SWS_Com_91012]. La interfaz posee el Service-ID 0x50 y se proporciona a través del archivo de cabecera Com.h [SWS_Com_91012].

La función Com_InvalidateSignal sirve para declarar no válida una señal en el módulo de comunicación [SWS_Com_00203]. Establece el valor de la señal pasada en el valor de invalidación definido en la configuración Com Signal Data Invalid Value [SWS_Com_00203]. El procesamiento se realiza de forma asíncrona [SWS_Com_00203]. Como único parámetro de transferencia se pasa el parámetro de entrada SignalId para la identificación de la señal; no existen parámetros de entrada/salida ni de salida [SWS_Com_00203].

Como valor de retorno, la llamada devuelve un estado del tipo uint8 que refleja el comportamiento de aceptación y de error [SWS_Com_00203]:

• E_OK: el servicio de invalidación se ha aceptado correctamente [SWS_Com_00203].
• COM_SERVICE_NOT_AVAILABLE: el servicio no está disponible. Esto ocurre cuando el grupo de I-PDU correspondiente está detenido, cuando no se ha configurado ningún Com Signal Data Invalid Value para el SignalId especificado o cuando la ejecución falla como consecuencia de un error de desarrollo [SWS_Com_00203].
• COM_BUSY: el servicio no se puede ejecutar actualmente porque el búfer TP está bloqueado [SWS_Com_00203].

En cuanto a la concurrencia, Com_InvalidateSignal no es reentrante para la misma señal, pero se puede ejecutar de forma paralela y reentrante para diferentes señales [SWS_Com_00203]. El servicio está declarado con el ID de servicio 0x10 y disponible a través del encabezado Com.h [SWS_Com_00203].

La función Com_InvalidateSignalGroup sirve para establecer todas las señales de grupo del grupo de señales transferido en sus respectivos valores ComSignalDataInvalidValue configurados y, con ello, invalidar el grupo de señales [SWS_Com_00557].

Uso y semántica

Como parámetro de entrada, el servicio espera el ID del grupo de señales que se va a invalidar (SignalGroupId de tipo Com_SignalGroupIdType) [SWS_Com_00557]. La llamada se procesa de forma asíncrona y devuelve un valor de estado de tipo uint8 [SWS_Com_00557].

Valores de retorno y tratamiento de errores

Se especifican los siguientes valores de retorno [SWS_Com_00557]:

• E_OK: la solicitud de invalidación se aceptó con éxito.
• COM_SERVICE_NOT_AVAILABLE: el servicio no está disponible porque el grupo de I-PDU correspondiente está detenido, no se configuró ningún ComSignalDataInvalidValue para ninguna de las señales de grupo o la llamada falla a causa de un error de desarrollo.
• COM_BUSY: el búfer del protocolo de transporte (TP-Buffer) está bloqueado actualmente.

Concurrencia y reentrancia

La función no es reentrante para el mismo grupo de señales, pero puede llamarse de forma concurrente (reentrante) para diferentes grupos de señales [SWS_Com_00557]. La declaración está disponible a través de Com.h [SWS_Com_00557].

La función síncrona Com_TriggerIPDUSend inicia la transmisión de la I-PDU identificada por el parámetro PduId [SWS_Com_00348]. Está disponible a través de la cabecera Com.h [SWS_Com_00348].

Condiciones de llamada y valores de retorno

La llamada solo inicia el envío si la I-PDU en cuestión está iniciada [SWS_Com_00861]. En consecuencia, el valor de retorno de tipo Std_ReturnType diferencia el estado de la I-PDU [SWS_Com_00348]:

• E_OK: la I-PDU se inició con éxito para su transmisión [SWS_Com_00348].
• E_NOT_OK: la I-PDU se encuentra en estado detenido, por lo que la transmisión no se pudo iniciar [SWS_Com_00348].

Comportamiento de búfer y de concurrencia

La función está especificada como no reentrante (Non Reentrant) [SWS_Com_00348]. Para I-PDUs grandes se contempla un mecanismo de almacenamiento en búfer: si se inicia una I-PDU grande a través de Com_TriggerIPDUSend mientras su búfer está bloqueado, AUTOSAR COM almacena provisionalmente la solicitud de envío y transmite la I-PDU solo cuando el búfer vuelve a estar disponible [SWS_Com_00867].

La función Com_TriggerIPDUSendWithMetaData sirve para iniciar de forma síncrona la transmisión de una I-PDU y actualizar previamente sus metadatos internos en el módulo AUTOSAR COM [SWS_Com_00858]. La llamada espera como parámetro PduId el identificador de la I-PDU que se va a enviar, así como con MetaData un puntero a los metadatos que se deben proporcionar [SWS_Com_00858]. El módulo COM copia los datos a partir de la dirección referenciada, considerando la longitud configurada globalmente del tipo de metadatos de la I-PDU, en su almacenamiento interno de datos e inicia la transmisión inmediatamente después [SWS_Com_00858].

Sin embargo, conforme a [SWS_Com_00862], el módulo COM solo puede iniciar la transmisión de la I-PDU si esta se encuentra en estado iniciada. En cambio, si la I-PDU está detenida, no se llega a disparar la transmisión.

El resultado de la ejecución se señaliza a través del valor de retorno:

• E_OK: La transmisión de la I-PDU se ha disparado correctamente [SWS_Com_00858].
• E_NOT_OK: La I-PDU está detenida; la transmisión no se pudo iniciar [SWS_Com_00858].

No se encuentran documentados en el payload códigos de error específicos para DET o DEM para este servicio.

En cuanto a la concurrencia, la interfaz está definida como no reentrante (Non Reentrant) [SWS_Com_00858], por lo que las llamadas paralelas deben excluirse o sincronizarse. Probablemente sea responsabilidad de la parte llamante asegurar la validez del puntero MetaData y un tamaño de búfer suficiente de acuerdo con la longitud de metadatos configurada. Pregunta Q-66c6abae0bbde275 (abierta)

La interfaz síncrona Com_SwitchIpduTxMode sirve para conmutar el modo de transmisión de una I-PDU y está especificada en el encabezado Com.h con el ID de servicio 0x27 [SWS_Com_00784]. Como parámetros se transfieren el identificador de la I-PDU correspondiente (PduId) así como el modo de transmisión deseado como valor booleano (Mode); no existe ningún valor de retorno ni parámetro de salida [SWS_Com_00784]. La llamada conmuta las propiedades de transmisión de forma síncrona y directa durante la ejecución [SWS_Com_00784].

Para la efectividad del cambio de modo, la especificación define dos casos:

• Si el modo de transmisión cambia mediante la llamada, el nuevo modo de funcionamiento entra en vigor inmediatamente para la I-PDU referenciada [SWS_Com_00784], [SWS_Com_00239].
• Si el modo de transmisión solicitado ya estaba activo para la I-PDU afectada, la llamada permanece completamente sin efecto [SWS_Com_00784].

En cuanto a la secuencia de envío posterior, rige para la interacción con el envío cíclico: si el modo de transmisión de una I-PDU se establece explícitamente a través de Com_SwitchIpduTxMode, el módulo AUTOSAR COM retarda los envíos cíclicos posteriores de esta I-PDU según el desfase temporal ComTxModeTimeOffset [SWS_Com_00881].

Con respecto a la concurrencia, la función está diseñada como reentrante para diferentes instancias de I-PDU [SWS_Com_00784]. Por el contrario, una llamada concurrente o paralela para la misma PduId se define como no reentrante y debe ser evitada por el llamador [SWS_Com_00784].

La función síncrona [SWS_Com_00001] sirve para la recuperación y copia síncronas de datos SDU de una PDU de transmisión (TxPduId) que se va a transmitir en el búfer proporcionado por el llamador. El llamador transfiere a través del parámetro de entrada y salida PduInfoPtr tanto la dirección de destino SduDataPtr como la capacidad de búfer máxima disponible en SduLength. Si los datos SDU caben por completo en el búfer, se copian, PduInfoPtr->SduLength se actualiza al número de bytes realmente copiados y el servicio concluye con éxito con E_OK [SWS_Com_00001].

Tratamiento de errores y condiciones límite

La función cancela la ejecución, no copia datos y devuelve E_NOT_OK si se cumple alguna de las siguientes condiciones:

• El tamaño de búfer proporcionado en PduInfoPtr->SduLength es menor que la longitud real de la PDU [SWS_Com_00001], [SWS_Com_00869]. En este caso, PduInfoPtr permanece sin cambios [SWS_Com_00001].
• La I-PDU correspondiente se encuentra en el estado detenido [SWS_Com_00884].

En caso de error (E_NOT_OK), el llamador no debe evaluar ni seguir utilizando el puntero PduInfoPtr, ya que puede hacer referencia a datos no válidos o representar un puntero NULL [SWS_Com_00001].

concurrencia

En cuanto a la concurrencia, la interfaz está diseñada como reentrante para diferentes ID de PDU, pero no debe llamarse de forma concurrente para la misma TxPduId [SWS_Com_00001].

La función Com_RxIndication sirve para señalar y transferir una PDU recibida desde un módulo de interfaz de comunicación subyacente hacia el módulo AUTOSAR COM [SWS_Com_00123]. La declaración de la función se proporciona a través del archivo de cabecera Com.h y posee el Service-ID 0x42 [SWS_Com_00123].

La llamada se realiza con semántica síncrona y no devuelve ningún valor de retorno (void) [SWS_Com_00123]. La interfaz no define parámetros de entrada/salida ni parámetros exclusivos de salida, sino únicamente dos parámetros de entrada [SWS_Com_00123]:

• RxPduId (tipo de datos PduIdType): representa el identificador unívoco de la PDU recibida [SWS_Com_00123].
• PduInfoPtr (puntero a PduInfoType constante): apunta a la estructura de datos que contiene la longitud de la PDU recibida (SduLength), un puntero al búfer con los datos de la PDU (SduDataPtr), así como los metadatos correspondientes [SWS_Com_00123].

En cuanto al comportamiento de concurrencia, Com_RxIndication está definida como reentrante para llamadas con diferentes ID de PDU, pero expresamente como no reentrante para la misma ID de PDU [SWS_Com_00123]. Interpretación: por tanto, es de suponer que los módulos llamadores de la interfaz de comunicación subyacente están obligados a sincronizar o serializar las llamadas concurrentes para ID de PDU idénticas a fin de preservar la coherencia de los datos. Pregunta Q-f3b6194f96c15091 (abierta)

La función de servicio síncrona Com_TpRxIndication se invoca en cuanto se ha recibido una I-PDU a través de la API TP [SWS_Com_00650]. Informa al módulo AUTOSAR COM sobre la finalización y el resultado del proceso de recepción. A través del parámetro id se identifica la I-PDU afectada, mientras que el parámetro result indica si la transmisión fue exitosa o falló [SWS_Com_00650]. La función no posee valor de retorno y está definida en la cabecera Com.h con el Service-ID 0x45 [SWS_Com_00650]. Como invocador presumiblemente actuaría una capa de transporte subyacente, como el módulo PduR o un módulo TP. Pregunta Q-d7006169cd162db4 (abierta)

Manejo de errores

Si se invoca Com_TpRxIndication con el valor de resultado E_NOT_OK para el parámetro result, el módulo COM trata todas las señales de la I-PDU grande recibida exactamente igual que las señales que han quedado invalidadas [SWS_Com_00838]. En este caso de error, el módulo ejecuta todas las ComDataInvalidActions configuradas para todas las señales y grupos de señales contenidos [SWS_Com_00838].

Concurrencia y condiciones de contorno

La función está especificada como reentrante y opera de forma síncrona [SWS_Com_00650]. Por lo tanto, puede invocarse en paralelo para diferentes I-PDUs, pero debería procesarse sin demora en el contexto de la instancia invocadora.

La función de callback síncrona Com_TxConfirmation se declara a través del encabezado Com.h y sirve como interfaz central de confirmación del módulo AUTOSAR COM [SWS_Com_00124]. Un módulo de interfaz de comunicación subyacente notifica con ella la transmisión exitosa de una PDU o el fallo del proceso de envío de vuelta al módulo Com [SWS_Com_00124].

Contexto de llamada y parámetros

La función se ejecuta de forma síncrona, posee el ID de servicio 0x40 y no proporciona valor de retorno (void) [SWS_Com_00124]. Espera dos parámetros de entrada:

• TxPduId (tipo PduIdType): identificador único de la PDU cuya transmisión ha concluido o ha fallado [SWS_Com_00124].
• result (tipo Std_ReturnType): estado de resultado del proceso de envío [SWS_Com_00124]. El valor E_OK confirma la transmisión realizada de la PDU, mientras que E_NOT_OK señala un fallo en la transmisión de la PDU [SWS_Com_00124].

Concurrencia y restricciones

Com_TxConfirmation es reentrante para diferentes ID de PDU, pero no reentrante para el mismo ID de PDU [SWS_Com_00124]. Interpretación: los llamadores de la capa subyacente deberían tener que evitar llamadas consecutivas o interruptivas con el mismo TxPduId desde diferentes contextos de ejecución, para que el estado de procesamiento interno del módulo Com permanezca consistente. Pregunta Q-146c1c92403b64fa (abierta)

Manejo de errores

La especificación no define valores de retorno específicos para este servicio y no indica mensajes de error DET o DEM separados [SWS_Com_00124]. Las transmisiones erróneas se transmiten exclusivamente a través del parámetro result con el valor de error E_NOT_OK al módulo Com [SWS_Com_00124].

Uso y semántica

La función Com_TpTxConfirmation se invoca después de que se haya transmitido una I-PDU en la red para notificar al módulo COM el resultado del proceso de envío [SWS_Com_00725]. A través del parámetro id de tipo PduIdType se identifica la I-PDU transmitida, mientras que result de tipo Std_ReturnType indica si la transmisión fue exitosa o falló [SWS_Com_00725]. La función no posee valor de retorno (void) y presenta una semántica de ejecución síncrona [SWS_Com_00725]. Está disponible a través del archivo de cabecera Com.h y posee el Service-ID 0x48 [SWS_Com_00725].

Manejo de errores

La transmisión de errores en esta interfaz se realiza exclusivamente a través del parámetro result, el cual refleja el éxito o el fracaso de la transferencia de la I-PDU [SWS_Com_00725]. En la especificación de la función no se contemplan códigos de error específicos ni notificaciones de error al módulo Default Error Tracer (DET) o al módulo Diagnostic Event Manager (DEM) [SWS_Com_00725].

Concurrencia y condiciones de contorno

La interfaz está especificada como reentrante y, por lo tanto, puede ejecutarse en paralelo [SWS_Com_00725]. Como restricción temporal, la llamada solo debe realizarse tras completarse la transmisión de la I-PDU en la red [SWS_Com_00725]. Interpretación: debido a la convención de nomenclatura y a la estructura del módulo, la llamada normalmente debería ser iniciada por un módulo de protocolo de transporte subyacente. Pregunta Q-8320e76ff63f62ce (abierta)

La función síncrona y reentrante Com_StartReception (disponible a través de Com.h, ID de servicio 0x46) se llama al comienzo de la recepción de una N-SDU, la cual se transmite sin fragmentar como Single Frame (SF) o fragmentada mediante un First Frame (FF) con Consecutive Frames (CF) subsiguientes [SWS_Com_00691].

A través del parámetro id se identifica la I-PDU y TpSduLength indica la longitud total de la N-SDU que se va a recibir [SWS_Com_00691]. El puntero info apunta a los datos útiles y a la longitud útil de la primera trama o trama individual, así como a los metadatos correspondientes; si no hay disponibles ni datos de trama ni metadatos, se transfiere NULL_PTR [SWS_Com_00691]. A través del parámetro de salida bufferSizePtr, la función proporciona el tamaño de búfer disponible que el módulo de protocolo de transporte utiliza para determinar el Block Size (BS) [SWS_Com_00691]. Si el servicio se llama con un TpSduLength de 0, devuelve el tamaño de búfer máximo disponible actualmente [SWS_Com_00691].

El resultado de la solicitud se devuelve como BufReq_ReturnType [SWS_Com_00691]:

• BUFREQ_OK: se acepta la conexión y continúa la recepción; bufferSizePtr indica el búfer disponible o señala 0 si no hay ningún búfer disponible con el tamaño solicitado [SWS_Com_00691].
• BUFREQ_E_NOT_OK: se rechaza la conexión y se cancela la recepción; el valor de bufferSizePtr permanece sin cambios [SWS_Com_00691].
• BUFREQ_E_OVFL: no se puede proporcionar ningún búfer con la longitud solicitada, tras lo cual se cancela la recepción; bufferSizePtr permanece sin cambios [SWS_Com_00691].

Uso y semántica de llamada

La función síncrona Com_CopyRxData se llama para transferir los datos recibidos de un segmento de I-PDU (N-PDU) a la capa superior [SWS_Com_00692]. En transmisiones segmentadas, cada llamada consecutiva a esta interfaz proporciona la siguiente parte correspondiente de los datos totales de la I-PDU [SWS_Com_00692].

Parámetros y gestión de búfer

• id: identifica de forma unívoca la I-PDU recibida [SWS_Com_00692].
• info: puntero a una estructura de tipo PduInfoType. Transfiere a través de SduDataPtr el puntero al búfer de origen y a través de SduLength el número de bytes que se van a copiar [SWS_Com_00692]. La indicación de 0 para SduLength sirve para consultar el tamaño de búfer actualmente disponible de la capa superior; en este caso de consulta pura, SduDataPtr puede establecerse en NULL_PTR [SWS_Com_00692].
• bufferSizePtr: puntero a una variable de tipo PduLengthType en la que se escribe el tamaño restante del búfer de recepción tras el proceso de copia [SWS_Com_00692].

Valores de retorno y propiedades

La función devuelve un estado de tipo BufReq_ReturnType [SWS_Com_00692]:

• BUFREQ_OK: los datos se han copiado con éxito en el búfer de destino [SWS_Com_00692].
• BUFREQ_E_NOT_OK: la copia de los datos ha fallado porque se ha producido un error [SWS_Com_00692].

La interfaz posee el ID de servicio 0x44, está especificada como reentrante y está disponible a través del encabezado Com.h [SWS_Com_00692].

La función síncrona y reentrante Com_CopyTxData es invocada por módulos subyacentes (como protocolos de transporte) para obtener paso a paso datos de envío para segmentos (N-PDUs) de una I-PDU desde el búfer de envío del módulo COM [SWS_Com_00693].

Uso y parámetros

Cada llamada pone a disposición la siguiente parte de los datos de la I-PDU [SWS_Com_00693]:

• id: identifica la I-PDU que se va a transmitir [SWS_Com_00693].
• info: indica a través de SduDataPtr el búfer de destino y a través de SduLength el número de bytes que se van a copiar. Se permite una longitud de 0 para comunicar cambios de estado mediante retry o consultar la cantidad de datos disponible; en este caso, SduDataPtr puede ser un NULL_PTR [SWS_Com_00693].
• retry: confirma datos enviados o solicita retransmisiones. Si retry es un NULL_PTR, los datos pueden eliminarse del búfer inmediatamente después de copiarse. Si retry apunta a una estructura RetryInfoType, TpDataState controla el mantenimiento en búfer: TP_CONFPENDING mantiene los datos en el búfer para la corrección de errores, TP_DATACONF confirma para su eliminación los datos copiados antes de la llamada, y TP_DATARETRY vuelve a copiar datos leídos previamente a partir del offset TxTpDataCnt [SWS_Com_00693].
• availableDataPtr: devuelve el número restante de bytes disponibles en el búfer de envío, lo que permite, por ejemplo, a protocolos de transporte dinámicos (como FrIsoTp) determinar los tamaños de segmento subsiguientes [SWS_Com_00693].

Valores de retorno y tratamiento de errores

El resultado de la función señala el éxito de la solicitud de búfer a través de BufReq_ReturnType [SWS_Com_00693]:

• BUFREQ_OK: los datos se copiaron completamente en el búfer de destino según lo solicitado [SWS_Com_00693].
• BUFREQ_E_BUSY: la cantidad de datos solicitada no está disponible en el búfer de envío. No se copia ningún dato y el módulo subyacente puede repetir la llamada más adelante [SWS_Com_00693].
• BUFREQ_E_NOT_OK: la solicitud ha fallado; no se copió ningún dato [SWS_Com_00693].

usar

La función síncrona Com_MainFunctionRx asume el procesamiento de recepción interno del módulo AUTOSAR COM para operaciones que no se procesan directamente en el contexto de ejecución de las APIs invocadas por el enrutador de PDU (PduR), como Com_RxIndication [SWS_Com_00398]. No posee parámetros de entrada ni de salida y no devuelve ningún valor de retorno [SWS_Com_00398]. La declaración se realiza a través de la cabecera SchM_Com.h; por lo tanto, es probable que el contexto de llamada se produzca típicamente de forma periódica mediante el Schedule Manager (SchM) [SWS_Com_00398]. Pregunta Q-48d121e36f62c6de (abierta)

Tratamiento de errores e inicialización

Si la función se ejecuta antes de la inicialización del módulo mediante Com_Init o después de una llamada a Com_DeInit, a diferencia de la mayoría de las APIs COM regulares no se genera ningún error COM_E_UNINIT (0x02), ya que Com_MainFunctionRx está explícitamente excluida de ello [SWS_Com_00804]. No existen códigos de error o de retorno específicos para esta interfaz [SWS_Com_00398].

Concurrencia y funcionamiento multi-instancia

En cuanto al contexto de ejecución y la reentrancia, se aplican los siguientes requisitos [SWS_Com_00398]:

• Reentrancia: la función no es reentrante para la misma instancia, pero se puede invocar en paralelo para diferentes instancias [SWS_Com_00398].
• Variante específica de la instancia: para cada contenedor ComMainFunctionRx definido en la configuración de la ECU se implementa una función independiente con la forma Com_MainFunctionRx_<shortName>, donde <shortName> corresponde al Short-Name del contenedor de configuración [SWS_Com_00398].

Uso y funcionamiento

La función Com_MainFunctionTx ejecuta las actividades de envío del módulo AUTOSAR COM que no se gestionan directamente dentro de las funciones COM invocadas por la RTE (como por ejemplo Com_SendSignal) ([SWS_Com_00399]). La ejecución se realiza de forma síncrona. No posee parámetros de entrada, de entrada/salida ni de salida, y no devuelve ningún valor de retorno ([SWS_Com_00399]). La interfaz se declara a través de SchM_Com.h; Interpretación: Debido a esta pertenencia a la cabecera, es de prever que el contexto de llamada se sitúe en la gestión de planificación (SchM). Pregunta Q-c33cfcf81700bcc5 (abierta)

Para cada contenedor configurado de una Com Main Function Tx en la configuración de la ECU, se debe implementar una función de instancia específica según el esquema de nomenclatura Com_MainFunctionTx_<shortName>, donde <shortName> corresponde al nombre corto del contenedor de configuración ([SWS_Com_00399]).

Concurrencia y restricciones

En cuanto a la reentrancia, Com_MainFunctionTx está diseñada como reentrante para diferentes instancias, pero no debe invocarse de forma reentrante para la misma instancia ([SWS_Com_00399]).

Tratamiento de errores y estado de inicialización

Conforme a [SWS_Com_00804], la llamada a servicios COM antes de la inicialización a través de Com_Init o después de la desinicialización a través de Com_DeInit provoca regularmente el error COM_E_UNINIT (0x02). Sin embargo, Com_MainFunctionTx está explícitamente excluida de esto y no genera tal error de inicialización en estos estados ([SWS_Com_00804]).

La función principal Com_MainFunctionRouteSignals (Service-ID 0x1a) sirve en el módulo AUTOSAR COM como interfaz síncrona central para el reenvío de señales ([SWS_Com_00400]). Su cometido consiste en invocar la parte de gateway de señales del módulo COM para que las señales recibidas que están previstas para un enrutamiento se reenvíen a sus destinos configurados ([SWS_Com_00400]).

Invocación y semántica

La interfaz de C sin parámetros posee la firma void Com_MainFunctionRouteSignals(void) ([SWS_Com_00400]). Se ejecuta de forma síncrona y no posee parámetros de entrada, entrada/salida o salida, ni valor de retorno ([SWS_Com_00400]). La declaración de la función principal se pone a disposición a través del archivo de cabecera SchM_Com.h ([SWS_Com_00400]). Interpretación: Debido a esta provisión a través de SchM_Com.h, es de prever que la llamada programada en el contexto de tarea se realice periódicamente mediante el planificador BSW (SchM). Pregunta Q-0f0b57034d6d6bf1 (abierta)

Instanciación y reentrancia

Para la integración, nomenclatura y concurrencia, [SWS_Com_00400] define los siguientes requisitos vinculantes:

• Implementación específica de la instancia: para cada instancia del contenedor de configuración ComMainFunctionRouteSignals presente en la configuración de la ECU debe implementarse una función propia según el esquema de nomenclatura Com_MainFunctionRouteSignals_<shortName> ([SWS_Com_00400]). En este caso, <shortName> corresponde al nombre corto del contenedor de configuración en cuestión.
• Comportamiento de reentrancia: la función es reentrante para llamadas de diferentes instancias ([SWS_Com_00400]). Sin embargo, para una misma instancia es explícitamente no reentrante y, por tanto, no debe ejecutarse de forma concurrente ([SWS_Com_00400]).

La función de callback Com_CbkTxAck sirve en el módulo Com para notificar el envío correcto de un mensaje [SWS_Com_00468]. Representa la clase de notificación 2 (notification class 2) y se invoca inmediatamente después de la transmisión correcta de la I-PDU que contiene el mensaje en cuestión [SWS_Com_00468].

Para el contexto de llamada y las propiedades de la interfaz se aplican las siguientes directrices según la especificación [SWS_Com_00468]:

• Firma y parámetros: la función de callback tiene la firma void Com_CbkTxAck (void). No recibe parámetros de entrada, entrada/salida ni salida, y no devuelve ningún valor de retorno [SWS_Com_00468].
• Sincronismo: la llamada está especificada como síncrona (Synchronous) [SWS_Com_00468].
• Reentrancia: el comportamiento de reentrancia está clasificado como don't care [SWS_Com_00468].
• Configuración: la interfaz está declarada como configurable (configurable) [SWS_Com_00468]. Interpretación: es probable que el nombre real de la función de callback se parametrice en la herramienta de configuración de manera específica para cada mensaje o señal. Pregunta Q-3670b7b04fd7c74c (abierta)

En la especificación no se definen códigos de error específicos, reacciones de error ni avisos a DET o DEM para este elemento [SWS_Com_00468]. Tampoco se especifican condiciones de secuencia adicionales respecto a otras llamadas [SWS_Com_00468].

La función de callback Com_CbkTxErr se invoca de forma síncrona cuando una transmisión no es posible porque el grupo de I-PDU asociado está detenido [SWS_Com_00491]. Corresponde a la clase de notificación 4 según las especificaciones subyacentes [SWS_Com_00491].

Invocación y semántica

• Firma y parámetros: la función no tiene parámetros de entrada, de entrada/salida ni de salida (void Com_CbkTxErr (void)) y no devuelve ningún valor de retorno [SWS_Com_00491].
• Comportamiento de ejecución: la llamada se realiza de forma síncrona («Synchronous»), mientras que para la reentrancia se especifica «don't care» [SWS_Com_00491].
• Disponibilidad: la interfaz de callback es configurable («configurable») [SWS_Com_00491].

Tratamiento de errores e interacción

La función sirve específicamente para señalizar a la capa que llama o superior el caso de error de una solicitud de envío impedida debido a un grupo de I-PDU detenido [SWS_Com_00491]. Como no se pasan parámetros, es de suponer que el contexto de la señal afectada o de la I-PDU se especifique probablemente a través de la configuración o de asignaciones específicas del módulo. Pregunta Q-d7153324d2eb2995 (abierta)

Uso y contexto de llamada

La función de callback Com_CbkTxTOut actúa como interfaz de notificación ante la falta de una transmisión correcta. Según [SWS_Com_00554], se llama inmediatamente después de que el mecanismo de supervisión de plazos límite (deadline monitoring mechanism) detecte un error de transmisión de un mensaje. La llamada se realiza de forma síncrona y corresponde a la clase de notificación 4. Dado que la firma void Com_CbkTxTOut(void) no tiene valores de transferencia ni de retorno, la señalización a la capa superior se efectúa sin parámetros.

Concurrencia y configuración

En cuanto a la reentrancia, la función está especificada según [SWS_Com_00554] con don't care. Presumiblemente, por tanto, corresponde al software de aplicación llamado tomar las medidas oportunas de seguridad para subprocesos (thread-safety) en caso de que los eventos de supervisión puedan llegar de forma concurrente. Pregunta Q-793a6c18d81de85e (abierta) La disponibilidad de la función de callback es configurable en el módulo de comunicación y se adapta a los requisitos de supervisión respectivos.

Manejo de errores

En [SWS_Com_00554] no se definen mensajes de error de DET o DEM independientes para Com_CbkTxTOut, ni valores de retorno para la confirmación de errores. El disparo del callback representa en sí mismo la reacción al error ante la superación de un plazo límite de envío.

La función de callback Com_CbkRxAck sirve en el módulo AUTOSAR COM como acuse de recibo configurable y representa la clase de notificación 1 según [17] [SWS_Com_00555]. El módulo COM invoca esta rutina de callback inmediatamente después de que un mensaje recibido se haya depositado y almacenado correctamente en el objeto de mensaje de recepción previsto para ello [SWS_Com_00555].

Uso y contexto de llamada

• Comportamiento de ejecución síncrono: la función está especificada como síncrona [SWS_Com_00555]. Se ejecuta directamente en el curso del proceso de almacenamiento, de modo que el contexto invocador del módulo COM espera a la ejecución del callback.
• Parámetros y valores de retorno: de acuerdo con la firma void Com_CbkRxAck (void), no se pasa ningún parámetro de entrada, ningún parámetro de entrada/salida ni ningún parámetro de salida [SWS_Com_00555]. Además, la función no devuelve ningún valor de retorno al módulo que la invoca [SWS_Com_00555].
• Disponibilidad: el mecanismo de llamada está a disposición del sistema como interfaz configurable [SWS_Com_00555].

Concurrencia y tratamiento de errores

Para la reentrancia se establece la propiedad «don't care» [SWS_Com_00555]. Es de suponer que esto signifique que la especificación COM no impone requisitos para una llamada reentrante y que los mecanismos de protección contra el acceso simultáneo son responsabilidad del usuario. Pregunta (abierta) Dado que no se definen valores de retorno ni códigos de error específicos o mensajes de error para DET o DEM [SWS_Com_00555], es probable que cualquier error durante el procesamiento deba tratarse por completo de manera local dentro de la función de callback.

Uso y semántica

La función de callback Com_CbkRxTOut sirve para notificar la ausencia de un mensaje esperado. Según [SWS_Com_00556], se invoca de forma inmediata en cuanto el mecanismo de deadline monitoring del módulo detecta un error en la recepción de un mensaje. Esta notificación corresponde a la clase de notificación 3 («notification class 3 of [17]») y está disponible como interfaz configurable [SWS_Com_00556].

La llamada se realiza de forma síncrona (Synchronous) sin parámetros de transferencia y sin valor de retorno (void Com_CbkRxTOut(void)) [SWS_Com_00556]. Por lo tanto, la función señaliza al receptor invocador o a la capa de software superior puramente el evento de timeout en sí, sin transmitir datos de contexto directamente en la llamada.

Concurrencia y restricciones

Para la reentrancia de la función se especifica don't care en la especificación [SWS_Com_00556]. Dado que la llamada se realiza de forma inmediata y síncrona tras la detección del error, presumiblemente la implementación de la rutina de callback deba diseñarse de modo que se ejecute con pocos bloqueos, para no retrasar indebidamente el deadline monitoring del módulo COM. Pregunta Q-88055efc50f5843b (abierta)

La función de callback Com_CbkInv notifica a las capas de software superiores sobre la recepción de datos de comunicación defectuosos o no válidos en el módulo AUTOSAR COM [SWS_Com_00536]. Se llama inmediatamente después de recibir una señal no válida o un grupo de señales no válido e informa al receptor de la presencia de un valor de señal no válido [SWS_Com_00536].

La interfaz posee la firma void Com_CbkInv(void), por lo que no recibe parámetros de transferencia y no devuelve ningún valor de retorno a la entidad emisora de la llamada [SWS_Com_00536]. La llamada se realiza de forma síncrona, mientras que el comportamiento de reentrancia se indica en la especificación como «don't care» [SWS_Com_00536]. Dado que no se pasan parámetros para identificar la señal afectada, es probable que el identificador Com_CbkInv sirva presumiblemente como plantilla de firma configurable para notificaciones específicas de señal. Pregunta Q-6e02e6bcf324eb93 (abierta)

En cuanto a la integración y el comportamiento del sistema, se aplican las siguientes condiciones límite:

• La provisión de la función es configurable, con lo que la notificación puede activarse según sea necesario por señal o grupo de señales [SWS_Com_00536].
• En el aspecto técnico, la función se corresponde con el requisito SWS_Com_00680 para el tratamiento de invalidación de señales recibidas en el módulo COM [SWS_Com_00536].
• No se indican rutinas de tratamiento de errores específicas, códigos de error ni mensajes de error a módulos de desarrollo o de diagnóstico como DET o DEM para esta interfaz [SWS_Com_00536].

La función de callback configurable Com_CbkCounterErr sirve para señalizar errores en la supervisión del contador de I-PDU según [SWS_Com_00726]. El módulo AUTOSAR COM la invoca de forma inmediata y síncrona cuando se detecta, en una I-PDU recibida, un valor de contador que no coincide con el valor de contador esperado. Esto permite detectar de forma temprana errores de secuencia en la recepción de mensajes.

La interfaz no tiene valor de retorno (void) y, al ser invocada, pasa tres parámetros de entrada para el análisis de errores ([SWS_Com_00726]):

• ComPduId (PduIdType): identificador de la I-PDU afectada en la que se ha producido el error de contador.
• ExpectedCounter (uint8): el valor de contador de la I-PDU esperado por el módulo COM.
• ReceivedCounter (uint8): el valor de contador realmente encontrado en el mensaje recibido.

En cuanto a la concurrencia, la reentrancia de la función se declara en la especificación como «don't care» ([SWS_Com_00726]). En [SWS_Com_00726] no se prescriben notificaciones de error específicas de DET o DEM para esta interfaz. Dado que la función de callback se define como configurable, es probable que se implemente en una capa superior, como la aplicación, para reaccionar de manera específica a la aplicación ante errores de transmisión o pérdidas de paquetes. Interpretación: dado que la llamada se realiza de forma inmediata y síncrona en el contexto del procesamiento de recepción de COM ([SWS_Com_00726]), la rutina invocada no debería realizar operaciones bloqueantes. Pregunta Q-a745eb5416fc156b (abierta)

La función de callback Com_CbkTxPrep sirve como notificación de que las señales o grupos de señales de una instancia dedicada de Com_MainFunctionTx se están preparando ahora para la transmisión [SWS_Com_91013]. La ejecución de la función se realiza de forma síncrona con respecto a la instancia llamadora [SWS_Com_91013]. De acuerdo con su firma void Com_CbkTxPrep(void), no recibe parámetros de entrada ni parámetros de entrada y salida o parámetros de salida, y no posee ningún valor de retorno [SWS_Com_91013].

La puesta a disposición de la interfaz está disponible mediante una configuración [SWS_Com_91013]. Siempre que el parámetro de configuración ComPreparationNotification esté configurado, la función correspondiente Com_CbkTxPrep debe llamarse dentro del MainFunctionTx correspondiente [SWS_Com_00886]. En este sentido, es obligatorio cumplir una condición estricta de orden temporal: la llamada debe tener lugar por completo antes de que se inicie el procesamiento propiamente dicho de las I-PDUs dentro de la función principal de Tx [SWS_Com_00886].

En cuanto al comportamiento de concurrencia y a las posibles restricciones, Com_CbkTxPrep se especifica como no reentrante (Non Reentrant) [SWS_Com_91013]. El contexto de invocación está estrictamente vinculado a la ejecución de la instancia correspondiente de MainFunctionTx [SWS_Com_91013]. Dado que el callback debe ejecutarse inmediatamente antes del inicio del procesamiento de la I-PDU, la función está integrada de forma síncrona en la rutina de transmisión correspondiente [SWS_Com_00886].

La función Com_RxIpduCallout es un callout configurable en el lado receptor que sirve para implementar mecanismos de filtrado de recepción específicos del usuario para I-PDUs [SWS_Com_00700]. La ejecución se realiza de forma síncrona y, en cuanto a la reentrancia, la interfaz está especificada como don't care [SWS_Com_00700].

A la llamada se le transfieren el identificador y los datos de la PDU recibida [SWS_Com_00700]:

• PduId: identificador de la I-PDU recibida [SWS_Com_00700].
• PduInfoPtr: puntero a una estructura PduInfoType, la cual proporciona la longitud (SduLength) así como un puntero a los datos útiles (SduDataPtr) de la I-PDU recibida [SWS_Com_00700].

En cuanto a la provisión de datos, [SWS_Com_00816] exige que el módulo AUTOSAR COM reenvíe íntegramente todos los datos de la I-PDU recibida a Com_RxIpduCallout, exactamente tal como fueron proporcionados por la capa del enrutador de PDU (PduR).

A través del valor de retorno booleano, el callout controla el procesamiento subsiguiente de la I-PDU en el módulo COM [SWS_Com_00700]:

• true: la I-PDU recibida continúa procesándose con normalidad [SWS_Com_00700].
• false: la I-PDU no se sigue procesando y, por tanto, se descarta [SWS_Com_00700].

La especificación no prevé códigos de error específicos, constantes de códigos de respuesta o notificaciones DET y DEM para este callout [SWS_Com_00700].

La función Com_TxIpduCallout sirve como callout configurable en el lado emisor y se invoca de forma síncrona para llevar a cabo un preprocesamiento o un filtrado de transmisión específico del usuario de una I-PDU saliente [SWS_Com_00346].

Parámetros y valor de retorno

• PduId (in): transfiere el identificador de la I-PDU que se va a transmitir [SWS_Com_00346].
• PduInfoPtr (inout): contiene la longitud de los datos útiles (SduLength), así como un puntero a los datos útiles (SduDataPtr) de la I-PDU [SWS_Com_00346]. Mediante esto se pueden inspeccionar o modificar los datos de la I-PDU antes del envío.
• Valor de retorno (boolean): controla el procesamiento posterior de la I-PDU [SWS_Com_00346]. Un valor de retorno de true provoca el envío regular de la I-PDU, mientras que false cancela cualquier procesamiento posterior y, con ello, la transmisión [SWS_Com_00346].

Concurrencia y configuración

El callout posee el Service-ID 0x29 y su reentrancia está definida en la especificación como «don't care» [SWS_Com_00346]. Interpretación: Dado que la reentrancia no está limitada, es de prever que las llamadas se produzcan en diferentes contextos de tarea en función de la solicitud de envío desencadenante, por lo que las implementaciones por parte del usuario deberían ser seguras para subprocesos (thread-safe) en caso de recursos compartidos. Pregunta Q-3ce35701879bb60c (abierta)

El tipo de enumeración Com_StatusType define el valor de estado para el módulo AUTOSAR COM y se proporciona a través del archivo de cabecera Com.h [SWS_Com_00819]. Este tipo sirve como valor de retorno del servicio de API Com_GetStatus(), con el cual los llamadores pueden consultar el estado actual de inicialización y funcionamiento del módulo de comunicación [SWS_Com_00819].

El rango de valores especificado de Com_StatusType distingue exactamente dos estados [SWS_Com_00819]:

• COM_UNINIT: indica que el módulo AUTOSAR COM no está inicializado o no se puede utilizar [SWS_Com_00819]. Este estado tiene obligatoriamente el valor numérico 0x00 (o valor 0) y constituye el valor predeterminado vinculante inmediatamente después de un reinicio del sistema [SWS_Com_00819].
• COM_INIT: señaliza que el módulo AUTOSAR COM se ha inicializado correctamente y, por tanto, está operativo y listo para su uso [SWS_Com_00819].

Para el software llamador, la evaluación de este valor de retorno sirve para verificar la operatividad del módulo de comunicación antes de su uso [SWS_Com_00819]. Mientras el servicio Com_GetStatus() devuelva el valor COM_UNINIT, el módulo COM se considera no inicializado o no utilizable [SWS_Com_00819]. Solo cuando el estado presenta el valor COM_INIT, el módulo está inicializado y operativo [SWS_Com_00819]. No se especifican más códigos de error ni valores de retorno para este tipo de enumeración [SWS_Com_00819].