AUTOSAR COM

Usage and Semantics

The function Com_Init initializes the internal and external interfaces as well as variables of the AUTOSAR COM layer for subsequent processing ([SWS_Com_00432]). The call is synchronous and non-reentrant (Non Reentrant) ([SWS_Com_00432]). config serves as the input parameter as a pointer to the configuration data of the COM module (const Com_ConfigType* config); there is no return value ([SWS_Com_00432]). In multi-partition configurations where main functions of the COM module are assigned to multiple partitions, COM can provide a dedicated initialization function per partition ([SWS_Com_00432]).

Sequence Conditions and Error Handling

Initialization via Com_Init is the functional prerequisite for regular use of the COM interfaces: If an API service is called before Com_Init or after a call to Com_DeInit, the error code COM_E_UNINIT (0x02) is generated ([SWS_Com_00804]). Calls to Com_GetStatus, Com_GetVersionInfo, Com_MainFunctionRx, Com_MainFunctionTx, and Com_MainFunctionRouteSignals are exclusively excluded from this error check ([SWS_Com_00804]).

Interaction during PDU and Signal Initialization

After execution of Com_Init, the actual inter-ECU communication initially remains deactivated ([SWS_Com_00432]). Interpretation: A subsequent activation of the respective I-PDU groups is therefore likely to be required for regular transmission and reception operation. Question Q-8407f9a6281c3764 (open) However, for certain data structures, Com_Init already performs direct initializations:

• If an I-PDU is not assigned to any I-PDU group, COM already starts this I-PDU within Com_Init as if it had been started via Com_IpduGroupStart with the initialization parameter set ([SWS_Com_00840]).
• For signal groups with configured array access (ComSignalGroupArrayAccess), Com_Init initializes the associated buffer area of the I-PDU based on the initial values (ComSignalInitValue) of all contained group signals ([SWS_Com_00850]).

Usage and Call Context

The synchronous function [SWS_Com_00130] (Interpretation: listed as 'Init' in the payload, but specifies signature void Com_DeInit(void)) terminates inter-ECU communication and puts the AUTOSAR COM module into the uninitialized state ([SWS_Com_00130]). Question Q-3e91d7d0a140cee0 (open) The service has service ID 0x02, requires no input parameters, returns no value, and is provided via header file Com.h ([SWS_Com_00130]).

Concurrency and Limitations

Regarding the call context, the function is defined as non-reentrant (Non Reentrant) ([SWS_Com_00130]). A concurrent or repeated call without prior re-initialization is therefore impermissible.

Interaction and Lifecycle

Due to the de-initialization, all previously started I-PDU groups are stopped ([SWS_Com_00130]). The following ordering conditions apply to a subsequent resumption of communication:

• The module must be re-initialized via the synchronous, non-reentrant service Com_Init, passing the configuration pointer config ([SWS_Com_00432]).
• Since inter-ECU communication remains disabled after calling Com_Init ([SWS_Com_00432]), the required I-PDU groups must subsequently be started explicitly again ([SWS_Com_00130]).

The synchronous function Com_IpduGroupStart (service ID 0x03, header Com.h) serves to start a preconfigured I-PDU group [SWS_Com_91001]. After the call, transmission of the associated I-PDUs is activated; for example, cyclic I-PDUs are sent cyclically from then on [SWS_Com_91001].

Usage and Parameters

The function has no return value and accepts two input parameters [SWS_Com_91001]:

• IpduGroupId: Unique identifier of the preconfigured I-PDU group to be started [SWS_Com_91001].
• initialize: A boolean flag for requesting data initialization of the I-PDUs of this group before starting [SWS_Com_91001].

If initialize is set to true, all I-PDUs of the group must be (re-)initialized before starting [SWS_Com_91001]. The I-PDUs then behave as they do immediately after a start-up of the COM module [SWS_Com_91001]. In particular, this includes the reinitialization of the previous value (old_value) of filter objects as well as the shadow buffers for signal groups [SWS_Com_91001].

Concurrency and Limitations

Regarding concurrency, Com_IpduGroupStart is reentrant for different I-PDU groups, but explicitly non-reentrant for the same I-PDU group [SWS_Com_91001].

use

The function Com_IpduGroupStop serves to stop a preconfigured I-PDU group in the AUTOSAR COM module [SWS_Com_91002]. The declaration is available via the header file Com.h and has the service ID 0x04 [SWS_Com_91002].

• Call syntax: void Com_IpduGroupStop (Com_IpduGroupIdType IpduGroupId) [SWS_Com_91002].
• Parameters: As the only parameter, the input parameter IpduGroupId of type Com_IpduGroupIdType is passed, which defines the identifier of the I-PDU group to be stopped [SWS_Com_91002]. Additional input/output (inout) or output parameters (out) do not exist [SWS_Com_91002].
• Return value: The interface does not provide a return value (void) [SWS_Com_91002].
• Execution behavior: The call is processed synchronously [SWS_Com_91002]. After calling Com_IpduGroupStop, communication of the affected group is stopped; this results, for example, in cyclic I-PDUs of the group no longer being transmitted [SWS_Com_91002].

Concurrency and Limitations

With respect to concurrency and reentrancy, it is specified that Com_IpduGroupStop is reentrant for different I-PDU groups, but must not be executed reentrantly for the same I-PDU group [SWS_Com_91002]. If the function is called in multitasking or multicore environments, the calling software must ensure that concurrent calls for one and the same group ID are prevented.

The synchronous function Com_EnableReceptionDM serves to enable reception deadline monitoring for all I-PDUs within a specified I-PDU group [SWS_Com_91004].

Usage and call context: The function is declared via the header file Com.h and has the service ID 0x06 [SWS_Com_91004]. As its only passed parameter, the signature void Com_EnableReceptionDM (Com_IpduGroupIdType IpduGroupId) expects the input parameter IpduGroupId of type Com_IpduGroupIdType, which represents the identifier of the I-PDU group for whose contained I-PDUs deadline monitoring is to be activated [SWS_Com_91004]. The execution is synchronous [SWS_Com_91004]. Neither input/output parameters nor output parameters exist, and no return value is provided (return type void) [SWS_Com_91004].

Concurrency and restrictions: Regarding concurrency, Com_EnableReceptionDM is reentrant for different I-PDU groups, but non-reentrant for the same I-PDU group [SWS_Com_91004]. Concurrent calls for the same group ID are therefore not permitted and must be avoided in the call context [SWS_Com_91004].

The synchronous function Com_DisableReceptionDM disables reception deadline monitoring for all I-PDUs within the passed I-PDU group [SWS_Com_91003].

use

The call is made via the interface void Com_DisableReceptionDM(Com_IpduGroupIdType IpduGroupId) with the identifier of the affected I-PDU group as an input parameter IpduGroupId [SWS_Com_91003]. The function has neither input/output nor output parameters and returns no return value (void) [SWS_Com_91003]. The service is declared with the service ID 0x05 in the header file Com.h [SWS_Com_91003].

Concurrency and Limitations

Regarding concurrency behavior, the service is reentrant for different I-PDU groups, but must not be called concurrently (non-reentrant) for the same I-PDU group [SWS_Com_91003].

The function Com_SendSignal serves to update a signal object identified by SignalId with the data referenced by pointer SignalDataPtr [SWS_Com_00197]. The call is processed asynchronously [SWS_Com_00197].

Return Values and Error Handling

The function returns a status of type uint8 [SWS_Com_00197]:

• E_OK: The service was accepted [SWS_Com_00197].
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group was stopped or the call failed due to a development error [SWS_Com_00197].
• COM_BUSY: Occurs when the TP buffer is locked for processing large data types [SWS_Com_00197].

Concurrency and Limitations

Regarding reentrancy, Com_SendSignal is non-reentrant for the same signal, but may be called concurrently for different signals [SWS_Com_00197]. The interface is provided via the header Com.h [SWS_Com_00197].

Interaction and Configuration

If configuration ComSignalGroupArrayAccess is defined for a signal group, calling Com_SendSignal for the group signals of this signal group is not supported [SWS_Com_00843].

Classic AUTOSAR function Com_SendDynSignal serves to update a dynamic-length signal object using the passed payload ([SWS_Com_00627]). The service has service ID 0x21 and operates asynchronously ([SWS_Com_00627]). As input parameters, the interface expects the identifier of the target signal (SignalId), a pointer to the signal payload to be transmitted (SignalDataPtr), and the current length of the dynamic signal (Length); output parameters are not present ([SWS_Com_00627]).

The return value of type uint8 reports the result of request acceptance ([SWS_Com_00627]):

• E_OK: The service request was successfully accepted ([SWS_Com_00627]).
• E_NOT_OK: Parameter Length exceeds the maximum length configured for this signal ComSignalLength ([SWS_Com_00627]).
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group is stopped or the service failed due to a development error ([SWS_Com_00627]).
• COM_BUSY: The TP buffer is locked ([SWS_Com_00627]).

Regarding concurrency, Com_SendDynSignal is reentrant for different signals, but not reentrant for the same signal ([SWS_Com_00627]). The function declaration is available via header Com.h ([SWS_Com_00627]).

The synchronous function Com_ReceiveSignal copies the data of the signal specified via SignalId to the memory address provided via pointer SignalDataPtr ([SWS_Com_00198]).

Usage and Semantics

The call processes the signal transfer synchronously and accepts the identifier SignalId (of type Com_SignalIdType) as input parameter and pointer SignalDataPtr (void*) to the destination buffer as output parameter ([SWS_Com_00198]). The interface is available via header Com.h ([SWS_Com_00198]).

Return Values and Error Handling

The return value of type uint8 signals the result of the function execution ([SWS_Com_00198]):

• E_OK: The service was successfully accepted and executed ([SWS_Com_00198]).
• COM_SERVICE_NOT_AVAILABLE: The corresponding I-PDU group was stopped or the service failed due to a development error ([SWS_Com_00198]).
• COM_BUSY: Occurs if the TP buffer is locked for processing large data types ([SWS_Com_00198]).

Concurrency and Limitations

Regarding reentrancy, Com_ReceiveSignal is non-reentrant for the same signal, but reentrant for different signals ([SWS_Com_00198]). In the event of parallel access to identical signal IDs, callers must consequently provide suitable synchronization.

In addition, there is a significant configuration constraint: If array-based access ComSignalGroupArrayAccess is configured for a signal group, calling Com_ReceiveSignal for the contained group signals of this signal group is not supported ([SWS_Com_00843]).

Usage and Semantics

The synchronous function Com_ReceiveDynSignal is used to receive a signal with dynamic length based on its SignalId [SWS_Com_00690]. The received signal data is copied to the memory location pointed to by SignalDataPtr [SWS_Com_00690]. Via the in-out parameter Length, the caller passes the maximum length that can be accommodated as an input value; after a successful copy operation, the actual length of the received dynamic signal is stored there [SWS_Com_00690].

Return Values and Error Handling

The function returns a status value of type uint8 [SWS_Com_00690]:

• E_OK: The service call was accepted and the data was successfully copied [SWS_Com_00690].
• E_NOT_OK: The provided buffer is too small because the input value of Length is smaller than the actual length of the received signal [SWS_Com_00690].
• COM_SERVICE_NOT_AVAILABLE: The corresponding I-PDU group was stopped or the service failed due to a development error [SWS_Com_00690].
• COM_BUSY: The TP buffer is currently locked [SWS_Com_00690].

Concurrency and Integration

Regarding reentrancy, Com_ReceiveDynSignal is non-reentrant for the same signal, but can be called reentrantly for different signals [SWS_Com_00690]. The declaration is available via Com.h [SWS_Com_00690].

The asynchronous function Com_SendSignalGroup serves to copy the contents of the assigned shadow buffer into the corresponding I-PDU [SWS_Com_00200]. As input parameter, it accepts the identifier SignalGroupId of the signal group to be transmitted [SWS_Com_00200].

Return Values and Error Handling

The return value signals the execution status of the service [SWS_Com_00200]:

• E_OK: The service call was successfully accepted [SWS_Com_00200].
• COM_SERVICE_NOT_AVAILABLE: The corresponding I-PDU group was stopped or the service failed due to a development error [SWS_Com_00200].
• COM_BUSY: The TP buffer is temporarily locked for the transmission of large data types [SWS_Com_00200].

Concurrency and Limitations

With respect to concurrency, the call is non-reentrant for the same group signal, but reentrant for different group signals [SWS_Com_00200]. Interpretation: The restriction is likely to refer to concurrent accesses to the same signal group. Question Q-2f3a6da092b51794 (open) Furthermore, calling Com_SendSignalGroup is not supported for a signal group if ComSignalGroupArrayAccess has been configured for it [SWS_Com_00843].

Interaction

The AUTOSAR COM module treats a call to Com_SendSignalGroupArray equivalently to Com_SendSignalGroup with regard to transmission properties, selection of the I-PDU transmission mode, and signal flow [SWS_Com_00847].

use

The synchronous function Com_ReceiveSignalGroup serves to receive signal groups. It copies the data of the received signal group from the corresponding I-PDU into the associated shadow buffer [SWS_Com_00201]. As an input parameter, the function expects the identifier of the signal group SignalGroupId of type Com_SignalGroupIdType [SWS_Com_00201]. The service is declared in header file Com.h [SWS_Com_00201].

Error Handling and Return Values

The service returns a status value of type uint8 that provides information about success or the cause of an error [SWS_Com_00201]:

• E_OK: The service was accepted successfully and the signal group was copied [SWS_Com_00201].
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group was stopped or the call failed due to a development error [SWS_Com_00201].
• COM_BUSY: The service reports this state if the TP buffer is locked for handling large data types [SWS_Com_00201].

Concurrency and Limitations

Regarding concurrency behavior, Com_ReceiveSignalGroup is implemented non-reentrantly for the same signal group, but reentrantly for different signal groups [SWS_Com_00201].

In addition, there is an essential restriction in interaction with array access: if configuration ComSignalGroupArrayAccess (ECUC_Com_10003) was defined for a signal group, calling Com_ReceiveSignalGroup for this signal group is not supported according to the specification [SWS_Com_00843].

The asynchronous function Com_SendSignalGroupArray copies the data of a signal group via the pointer SignalGroupArrayPtr directly into the assigned I-PDU [SWS_Com_00851]. The passed data must correspond exactly to the array representation of the respective signal group [SWS_Com_00851], [SWS_Com_00852].

The identifier of the signal group (SignalGroupId) as well as the reference to the signal group array (SignalGroupArrayPtr) are passed as input parameters [SWS_Com_00851]. The service provides the following return values [SWS_Com_00851]:

• E_OK: The service call was successfully accepted.
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group has been stopped or the call failed due to a development error.
• COM_BUSY: The transport protocol buffer (TP buffer) is locked for processing large data types.

Regarding concurrency, the function is non-reentrant for the same signal group, but may be called reentrantly for different signal groups [SWS_Com_00851]. The call is only available if the configuration switch ComEnableSignalGroupArrayApi is enabled [SWS_Com_00853].

With respect to the transmission properties of signal groups, the selection of the I-PDU transmission mode, and the signal flow, Com_SendSignalGroupArray is treated by the AUTOSAR COM module fully analogously to Com_SendSignalGroup [SWS_Com_00847].

Usage and Configuration

The synchronous function Com_ReceiveSignalGroupArray copies the received signal group as a byte array representation from the I-PDU into the memory area referenced by SignalGroupArrayPtr [SWS_Com_00854], [SWS_Com_00855]. The function is available exclusively if the configuration switch ComEnableSignalGroupArrayApi is enabled [SWS_Com_00856]. It supports reception filtering and Transmission Mode Selection with the filters ALWAYS, NEVER, MASKED_NEW_EQUALS_X, MASKED_NEW_DIFFERS_X, MASKED_NEW_DIFFERS_MASKED_OLD, and ONE_EVERY_N [SWS_Com_00848].

Data Copy and Error Handling

Upon invocation, the SignalGroupId and a pointer to the destination array are passed, at whose position the AUTOSAR COM module copies the data of the I-PDU [SWS_Com_00849]. Even if the I-PDU group is stopped and the service returns COM_SERVICE_NOT_AVAILABLE, the module always copies the latest known data or the initial values ComSignalInitValues if no data has been written yet [SWS_Com_00857].

Return Values and Concurrency

Possible return values of the service are [SWS_Com_00854]:

• E_OK: The service was successfully accepted.
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group is stopped or the service failed due to a development error.
• COM_BUSY: The TP buffer is locked for processing large data types.

Regarding concurrency, the function is reentrant for different signal groups, but non-reentrant for the same signal group [SWS_Com_00854].

The synchronous function Com_ReceiveSignalWithMetaData serves to read out received signal data together with its metadata from the communication module Com [SWS_Com_91005]. When called, the service copies the data of the signal addressed via the SignalId to the memory location referenced by SignalDataPtr and stores the received metadata at position MetaDataPtr [SWS_Com_91005].

Parameters and call context

The interface is available via the header Com.h and is identified via the service ID 0x49 [SWS_Com_91005]. The parameter structure is divided as follows:

• SignalId (in): Identifier of the signal to be received [SWS_Com_91005].
• SignalDataPtr (out): Pointer to the storage location for storing the received signal data [SWS_Com_91005].
• MetaDataPtr (out): Pointer to the memory area for accommodating the signal metadata [SWS_Com_91005].

The function returns a return value of type uint8, for which no specific error values are documented in the present standard section [SWS_Com_91005].

Concurrency and Limitations

Regarding reentrancy, the service is reentrant for different signals, but non-reentrant for the same signal [SWS_Com_91005]. In the case of parallel or interrupting calls with identical SignalId, external protection by the caller is consequently likely required to ensure data consistency. Question Q-51cbdce3d4f59f24 (open)

Usage and Semantics

The function Com_ReceiveDynSignalWithMetaData is provided via the header file Com.h and is used for the synchronous reception of signals with dynamic length including their metadata [SWS_Com_91006]. When called, the service copies the data of the signal identified via SignalId into the buffer referenced by SignalDataPtr [SWS_Com_91006]. The received metadata is stored at pointer MetaDataPtr, while the actual length of the received dynamic signal is written to the position of Length [SWS_Com_91006].

Return Values and Error Handling

The service returns a status value of type uint8 [SWS_Com_91006]:

• E_OK: The reception service was accepted successfully [SWS_Com_91006].
• E_NOT_OK: Occurs if the passed value of Length is smaller than the actual length of the received dynamic signal [SWS_Com_91006]. Interpretation: The caller must provide the buffer size in advance via Length, so that the parameter de facto acts as a combined input and output. Question Q-8ad420c74748f219 (open)
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group is stopped or the call failed due to a development error [SWS_Com_91006].
• COM_BUSY: The TP buffer is currently locked [SWS_Com_91006].

Concurrency and Limitations

With regard to concurrency, the function is reentrant for different signals, but must not be called reentrantly for the same signal [SWS_Com_91006]. Parallel calls for the same SignalId must therefore be synchronized at caller level.

The synchronous function Com_ReceiveSignalGroupWithMetaData is used to receive a signal group including associated metadata via the interface Com.h [SWS_Com_91007]. It takes the identifier SignalGroupId as an input parameter and copies the received data of the signal group from the I-PDU into the local shadow buffer [SWS_Com_91007]. At the same time, the service saves the received metadata at the destination address referenced via the output parameter MetaDataPtr [SWS_Com_91007].

The error and return behavior comprises three status values: E_OK signals the successful acceptance of the service [SWS_Com_91007]. The return value COM_SERVICE_NOT_AVAILABLE indicates that the associated I-PDU group is stopped or a development error has occurred [SWS_Com_91007]. If the error code COM_BUSY occurs, the TP buffer is locked for processing large data types [SWS_Com_91007]. Regarding concurrency, the function is reentrant for different signal groups, but non-reentrant for the same signal group [SWS_Com_91007]. Since the specification does not state any ISR restrictions, the call is likely to take place synchronously at task level by the higher-level software component. Question Q-a23cf67bae724ae1 (open)

In interaction, the function extends the reception path with metadata analogously to Com_ReceiveSignalWithMetaData for individual signals [SWS_Com_91005]. The provided metadata corresponds to the PDU information previously received at the interface via Com_RxIndication [SWS_Com_00123]. To signal invalid data contents, Com_InvalidateSignalGroup can additionally be used in the overall sequence [SWS_Com_00557].

use

The synchronous service Com_ReceiveSignalGroupArrayWithMetaData (service ID 0x4c, available via Com.h) copies the received signal group array representation from the I-PDU into the memory location provided via the pointer SignalGroupArrayPtr [SWS_Com_91008]. At the same time, the received metadata is written to the position specified by the parameter MetaDataPtr [SWS_Com_91008]. The function has no return value (void) [SWS_Com_91008].

Error handling

The specification defines no return values for this service and does not list any specific error codes [SWS_Com_91008]. Interpretation: Any error states in call parameters are likely handled internally and via the module's error reporting; however, concrete DET or DEM messages are not evident from the specification excerpt. Question (open)

Concurrency and Limitations

With regard to concurrency, the function is reentrant for different signal groups, but non-reentrant for the same signal group [SWS_Com_91008]. Parallel calls with an identical SignalGroupId must be prevented by the caller. Interpretation: Callers are likely also required to provide sufficiently dimensioned destination buffers, as the interface carries no length parameters. Question (open)

Interaction

The provision of data in the PDU buffer requires that a reception indication via Com_RxIndication has previously taken place, which also delivers the metadata to the COM module [SWS_Com_00123]. The function extends the reception interfaces for metadata analogously to Com_ReceiveSignalWithMetaData for individual signals [SWS_Com_91005] and differs from regular signal retrieval via Com_ReceiveSignal [SWS_Com_00198].

The function Com_SendSignalWithMetaData ([SWS_Com_91009]) is used to asynchronously update a signal object specified by SignalId with payload data via SignalDataPtr and associated metadata via MetaDataPtr. The service is available via the header Com.h.

• Call and concurrency: The call is performed asynchronously ([SWS_Com_91009]). The function is reentrant for different signals, but non-reentrant for the same signal identifier (SignalId) ([SWS_Com_91009]).
• Return values and error handling: The function returns a status value of type uint8 ([SWS_Com_91009]):
  • E_OK: The transmit request was successfully accepted by the module ([SWS_Com_91009]).
  • COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group is stopped or the call failed due to a development error ([SWS_Com_91009]).
  • COM_BUSY: The TP buffer is locked for processing large data types ([SWS_Com_91009]).
• Interaction: In contrast to the basic transmission service Com_SendSignal ([SWS_Com_00197]), this function passes explicit metadata. It forms the transmit-side counterpart to the reception service Com_ReceiveSignalWithMetaData ([SWS_Com_91005]) and complements I-PDU-related metadata services such as Com_TriggerIPDUSendWithMetaData ([SWS_Com_00858]).

Usage and Semantics

The function Com_SendDynSignalWithMetaData is used to asynchronously update a signal object identified via SignalId (type Com_SignalIdType) with signal data of dynamic length and the associated metadata [SWS_Com_91010]. The payload data to be transmitted is referenced via the pointer SignalDataPtr (type void*), while MetaDataPtr (type uint8*) points to the metadata [SWS_Com_91010]. The actual length of the dynamic signal to be sent is passed via parameter Length (type uint16) [SWS_Com_91010].

Return Values and Error Handling

The return value of type uint8 signals whether the service was accepted or which error is present [SWS_Com_91010]:

• E_OK: The service call was successfully accepted for processing [SWS_Com_91010].
• E_NOT_OK: The passed Length exceeds the ComSignalLength configured for this signal [SWS_Com_91010].
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group was stopped or the call failed due to a development error [SWS_Com_91010].
• COM_BUSY: The TP buffer is currently locked, which is why the signal cannot be sent [SWS_Com_91010].

Concurrency and Integration

With regard to concurrency, the function is reentrant for different signals, but non-reentrant for the same signal [SWS_Com_91010]. The interface has the service ID 0x4e and is made available in module Com via the header file Com.h [SWS_Com_91010].

The function Com_SendSignalGroupWithMetaData (referred to in the data model as Data) is used to asynchronously transmit a signal group along with metadata to module Com [SWS_Com_91011]. When called, the service copies the current content of the assigned shadow buffer into the associated I-PDU, with the metadata being provided via pointer MetaDataPtr [SWS_Com_91011].

The input parameters comprise the identifier of the signal group (SignalGroupId) and the pointer to the metadata (MetaDataPtr) [SWS_Com_91011]. The return values report the result of the service request:

• E_OK: The service was accepted successfully [SWS_Com_91011].
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group was stopped or execution failed due to a development error [SWS_Com_91011].
• COM_BUSY: The TP buffer is locked for the transmission of large data types [SWS_Com_91011].

Regarding concurrency, the call is reentrant for different signals, but non-reentrant for the same group signal; analogously to parameter SignalGroupId, this is likely to refer to the respective signal group [SWS_Com_91011]. Question Q-91171d77370ae50a (open) In interaction with module Com, the service complements the sending of individual signals such as Com_SendSignal [SWS_Com_00197] and the invalidation of signal groups via Com_InvalidateSignalGroup [SWS_Com_00557]. Furthermore, it corresponds to the reception service Com_ReceiveSignalWithMetaData [SWS_Com_91005] and the PDU-based transmit call Com_TriggerIPDUSendWithMetaData [SWS_Com_00858].

Usage and Parameters

The function Com_SendSignalGroupArrayWithMetaData is used to asynchronously transmit a signal group along with associated metadata [SWS_Com_91012]. When called, the service copies the content of the passed pointer SignalGroupArrayPtr directly into the assigned I-PDU [SWS_Com_91012]. The provided data must strictly correspond to the array representation of the signal group, which is identified via the parameter SignalGroupId of type Com_SignalGroupIdType [SWS_Com_91012]. Additional metadata of the signal group is passed to the communication layer via the pointer MetaDataPtr [SWS_Com_91012].

Return Values and Error Handling

The function returns a status value of type uint8 that indicates the success of the transfer or the respective cause of error [SWS_Com_91012]:

• E_OK: The service call was successfully accepted by the COM layer [SWS_Com_91012].
• COM_SERVICE_NOT_AVAILABLE: The associated I-PDU group is stopped or the call failed due to a development error [SWS_Com_91012].
• COM_BUSY: The transport protocol buffer (TP buffer) is locked for the processing of large data types [SWS_Com_91012].

Concurrency and Limitations

According to the specification, the service is classified as non-reentrant (Non Reentrant), which is why concurrent or interrupting calls are not permitted [SWS_Com_91012]. The interface has the service ID 0x50 and is provided via the header file Com.h [SWS_Com_91012].

Function Com_InvalidateSignal serves to invalidate a signal in communication module [SWS_Com_00203]. It sets the value of the passed signal to the invalid value defined in the configuration Com Signal Data Invalid Value [SWS_Com_00203]. Processing takes place asynchronously [SWS_Com_00203]. Input parameter SignalId is passed as the only input parameter to identify the signal; input/output or output parameters do not exist [SWS_Com_00203].

As return value, the call returns a status of type uint8 representing acceptance and error behavior [SWS_Com_00203]:

• E_OK: The invalidation service was accepted successfully [SWS_Com_00203].
• COM_SERVICE_NOT_AVAILABLE: The service is not available. This occurs if the associated I-PDU group is stopped, if no Com Signal Data Invalid Value has been configured for the specified SignalId, or if execution fails due to a development error [SWS_Com_00203].
• COM_BUSY: The service cannot be executed currently because the TP buffer is locked [SWS_Com_00203].

Regarding concurrency, Com_InvalidateSignal is non-reentrant for the same signal, but may be executed in parallel and reentrantly for different signals [SWS_Com_00203]. The service is declared under service ID 0x10 and available via header Com.h [SWS_Com_00203].

The function Com_InvalidateSignalGroup serves to set all group signals of the passed signal group to their respective configured ComSignalDataInvalidValue values and thus invalidate the signal group [SWS_Com_00557].

Usage and Semantics

The service expects the ID of the signal group to be invalidated (SignalGroupId of type Com_SignalGroupIdType) as an input parameter [SWS_Com_00557]. The call is processed asynchronously and returns a status value of type uint8 [SWS_Com_00557].

Return Values and Error Handling

The following return values are specified [SWS_Com_00557]:

• E_OK: The invalidation request was successfully accepted.
• COM_SERVICE_NOT_AVAILABLE: The service is not available because the corresponding I-PDU group is stopped, no ComSignalDataInvalidValue has been configured for any of the group signals, or the call fails due to a development error.
• COM_BUSY: The transport protocol buffer (TP buffer) is currently locked.

Concurrency and Reentrancy

The function is non-reentrant for the same signal group, but may be called concurrently (reentrantly) for different signal groups [SWS_Com_00557]. The declaration is available via Com.h [SWS_Com_00557].

The synchronous function Com_TriggerIPDUSend triggers the transmission of the I-PDU identified by parameter PduId [SWS_Com_00348]. It is available via header Com.h [SWS_Com_00348].

Call conditions and return values

The call triggers transmission only if the affected I-PDU is started [SWS_Com_00861]. Accordingly, the return value of type Std_ReturnType differentiates the status of the I-PDU [SWS_Com_00348]:

• E_OK: The I-PDU was successfully triggered for transmission [SWS_Com_00348].
• E_NOT_OK: The I-PDU is in the stopped state, so transmission could not be triggered [SWS_Com_00348].

Buffering and concurrency behavior

The function is specified as non-reentrant (Non Reentrant) [SWS_Com_00348]. A buffering mechanism is provided for large I-PDUs: if a large I-PDU is triggered via Com_TriggerIPDUSend while its buffer is locked, AUTOSAR COM temporarily stores the transmit request and transmits the I-PDU only once the buffer is available again [SWS_Com_00867].

The function Com_TriggerIPDUSendWithMetaData serves to trigger the transmission of an I-PDU synchronously and previously update its internal metadata in the AUTOSAR COM module [SWS_Com_00858]. As parameter PduId, the call expects the identifier of the I-PDU to be sent, and with MetaData a pointer to the metadata to be provided [SWS_Com_00858]. Taking into account the globally configured length of the I-PDU's metadata type, the COM module copies the data starting from the referenced address into its internal data storage and immediately afterwards triggers the transmission [SWS_Com_00858].

According to [SWS_Com_00862], however, the COM module may trigger the transmission of the I-PDU only if the I-PDU is in the started state. If, on the other hand, the I-PDU is stopped, the transmission is not triggered.

The result of the execution is signaled via the return value:

• E_OK: Transmission of the I-PDU was successfully triggered [SWS_Com_00858].
• E_NOT_OK: The I-PDU is stopped; the transmission could not be triggered [SWS_Com_00858].

Specific error codes for DET or DEM are not documented in the payload for this service.

With regard to concurrency, the interface is defined as non-reentrant (Non Reentrant) [SWS_Com_00858], which is why parallel calls must be excluded or synchronized. Presumably, it is the caller's responsibility to ensure the validity of the pointer MetaData and a sufficient buffer size according to the configured metadata length. Question Q-66c6abae0bbde275 (open)

The synchronous interface Com_SwitchIpduTxMode serves to switch the transmission mode of an I-PDU and is specified in the header Com.h under the service ID 0x27 [SWS_Com_00784]. The identifier of the relevant I-PDU (PduId) and the desired transmission mode as a boolean value (Mode) are passed as parameters; no return value or output parameter exists [SWS_Com_00784]. The call switches the transmission properties synchronously and directly during execution [SWS_Com_00784].

The specification defines two cases for the effectiveness of the mode change:

• If the transmission mode changes as a result of the call, the new operating mode takes effect immediately for the referenced I-PDU [SWS_Com_00784], [SWS_Com_00239].
• If the requested transmission mode was already active for the affected I-PDU, the call remains completely without effect [SWS_Com_00784].

Regarding the further transmission process, the following applies to the interaction with cyclic transmission: If the transmission mode of an I-PDU is explicitly set via Com_SwitchIpduTxMode, the AUTOSAR COM module delays the subsequent cyclic transmissions of this I-PDU by the time offset ComTxModeTimeOffset [SWS_Com_00881].

With respect to concurrency, the function is designed to be reentrant for different I-PDU instances [SWS_Com_00784]. A concurrent or parallel call for the same PduId, however, is defined as non-reentrant and must be prevented by the caller [SWS_Com_00784].

The synchronous function [SWS_Com_00001] serves to synchronously retrieve and copy SDU data of a transmit PDU (TxPduId) to be transmitted into the buffer provided by the caller. Via the in/out parameter PduInfoPtr, the caller passes both the destination address SduDataPtr and the maximum available buffer capacity in SduLength. If the SDU data fits completely into the buffer, it is copied, PduInfoPtr->SduLength is updated to the number of bytes actually copied, and the service terminates successfully with E_OK [SWS_Com_00001].

Error Handling and Boundary Conditions

The function aborts execution, copies no data, and returns E_NOT_OK if one of the following conditions applies:

• The provided buffer size in PduInfoPtr->SduLength is smaller than the actual PDU length [SWS_Com_00001], [SWS_Com_00869]. In this case, PduInfoPtr remains unchanged [SWS_Com_00001].
• The corresponding I-PDU is in the stopped state [SWS_Com_00884].

In case of error (E_NOT_OK), the caller must not evaluate or reuse pointer PduInfoPtr, as it may point to invalid data or represent a NULL pointer [SWS_Com_00001].

Concurrency

With regard to concurrency, the interface is designed to be reentrant for different PDU IDs, but must not be called concurrently for the same TxPduId [SWS_Com_00001].

The function Com_RxIndication serves to signal and pass a received PDU from an underlying communication interface module to the AUTOSAR COM module [SWS_Com_00123]. The function declaration is provided via the header file Com.h and has the service ID 0x42 [SWS_Com_00123].

The call is performed with synchronous semantics and returns no return value (void) [SWS_Com_00123]. The interface defines neither input/output parameters nor pure output parameters, but exclusively two input parameters [SWS_Com_00123]:

• RxPduId (data type PduIdType): Represents the unique identifier of the received PDU [SWS_Com_00123].
• PduInfoPtr (pointer to constant PduInfoType): References the data structure containing the length of the received PDU (SduLength), a pointer to the buffer with the PDU data (SduDataPtr), and associated metadata [SWS_Com_00123].

Regarding concurrency behavior, Com_RxIndication is defined as reentrant for calls with different PDU IDs, but explicitly as non-reentrant for the same PDU ID [SWS_Com_00123]. Interpretation: Calling modules of the underlying communication interface are therefore likely obliged to synchronize or serialize concurrent calls for identical PDU IDs in order to maintain data consistency. Question Q-f3b6194f96c15091 (open)

The synchronous service function Com_TpRxIndication is called as soon as an I-PDU has been received via the TP API [SWS_Com_00650]. It informs the AUTOSAR COM module about the completion and the result of the reception process. The affected I-PDU is identified via parameter id, while parameter result indicates whether the transmission was successful or failed [SWS_Com_00650]. The function has no return value and is defined in header Com.h with service ID 0x45 [SWS_Com_00650]. A lower transport layer such as the PduR or a TP module is likely to act as caller. Question Q-d7006169cd162db4 (open)

Error handling

If Com_TpRxIndication is called with the result value E_NOT_OK for parameter result, the COM module treats all signals of the received large I-PDU exactly like signals that have become invalid [SWS_Com_00838]. In this error case, the module executes all configured ComDataInvalidActions for all contained signals and signal groups [SWS_Com_00838].

Concurrency and Constraints

The function is specified as reentrant and operates synchronously [SWS_Com_00650]. It can therefore be called concurrently for different I-PDUs, but should be processed without delay in the context of the calling instance.

The synchronous callback function Com_TxConfirmation is declared via header Com.h and serves as the central confirmation interface of the AUTOSAR COM module [SWS_Com_00124]. A lower-layer communication interface module uses it to report the successful transmission of a PDU or the failure of the transmission process back to module Com [SWS_Com_00124].

Call Context and Parameters

The function is executed synchronously, has service ID 0x40, and returns no return value (void) [SWS_Com_00124]. It expects two input parameters:

• TxPduId (type PduIdType): Unique identifier of the PDU whose transmission has completed or failed [SWS_Com_00124].
• result (type Std_ReturnType): Result status of the transmission process [SWS_Com_00124]. The value E_OK confirms the successful transmission of the PDU, whereas E_NOT_OK signals a failure of the PDU transmission [SWS_Com_00124].

Concurrency and Limitations

Com_TxConfirmation is reentrant for different PDU IDs, but not reentrant for the same PDU ID [SWS_Com_00124]. Interpretation: Callers from the lower layer presumably must avoid consecutive or preemptive calls with the same TxPduId from different execution contexts so that the internal processing status of the Com module remains consistent. Question Q-146c1c92403b64fa (open)

Error handling

The specification defines no specific return values for this service and does not indicate separate DET or DEM error messages [SWS_Com_00124]. Erroneous transmissions are transmitted to the Com module exclusively via parameter result with error value E_NOT_OK [SWS_Com_00124].

Usage and Semantics

The function Com_TpTxConfirmation is called after an I-PDU has been transmitted on the network to notify the COM module about the result of the transmission process [SWS_Com_00725]. Via the parameter id of type PduIdType, the transmitted I-PDU is identified, while result of type Std_ReturnType indicates whether the transmission was successful or failed [SWS_Com_00725]. The function has no return value (void) and exhibits synchronous execution semantics [SWS_Com_00725]. It is available via the header file Com.h and has the service ID 0x48 [SWS_Com_00725].

Error handling

Error reporting on this interface is performed exclusively via the parameter result, which indicates the success or failure of the I-PDU transfer [SWS_Com_00725]. Specific error codes and error messages to the Default Error Tracer (DET) or the Diagnostic Event Manager (DEM) module are not specified in the functional specification [SWS_Com_00725].

Concurrency and Constraints

The interface is specified as reentrant and may thus be executed in parallel [SWS_Com_00725]. As a temporal constraint, the call may only occur after the transmission of the I-PDU on the network has been completed [SWS_Com_00725]. Interpretation: Due to the naming convention and module structure, the call is likely typically initiated by an underlying transport protocol module. Question Q-8320e76ff63f62ce (open)

The synchronous and reentrant function Com_StartReception (available via Com.h, service ID 0x46) is called at the start of the reception of an N-SDU, which is transmitted unfragmented as a Single Frame (SF) or fragmented via a First Frame (FF) with subsequent Consecutive Frames (CF) [SWS_Com_00691].

The I-PDU is identified via the parameter id, and TpSduLength indicates the total length of the N-SDU to be received [SWS_Com_00691]. The pointer info points to the payload and payload length of the first or single frame as well as to associated metadata; if neither frame data nor metadata is available, NULL_PTR is passed [SWS_Com_00691]. Via the output parameter bufferSizePtr, the function provides the available buffer size, which the transport protocol module uses to determine the block size (BS) [SWS_Com_00691]. If the service is called with a TpSduLength of 0, it returns the currently maximum available buffer size [SWS_Com_00691].

The result of the request is returned as BufReq_ReturnType [SWS_Com_00691]:

• BUFREQ_OK: The connection is accepted and reception continues; bufferSizePtr indicates the available buffer or signals 0 if no buffer of the requested size is available [SWS_Com_00691].
• BUFREQ_E_NOT_OK: The connection is rejected and reception is aborted; the value of bufferSizePtr remains unchanged [SWS_Com_00691].
• BUFREQ_E_OVFL: No buffer of the required length can be provided, whereupon reception aborts; bufferSizePtr remains unchanged [SWS_Com_00691].

Usage and invocation semantics

The synchronous function Com_CopyRxData is called to pass the received data of an I-PDU segment (N-PDU) to the upper layer [SWS_Com_00692]. For segmented transmissions, each consecutive call to this interface provides the respective next part of the total I-PDU data [SWS_Com_00692].

Parameters and Buffer Management

• id: Uniquely identifies the received I-PDU [SWS_Com_00692].
• info: Pointer to a structure of type PduInfoType. Via SduDataPtr, it passes the pointer to the source buffer and via SduLength, the number of bytes to be copied [SWS_Com_00692]. Specifying 0 for SduLength serves to query the currently available buffer size of the upper layer; in this pure query case, SduDataPtr may be set to NULL_PTR [SWS_Com_00692].
• bufferSizePtr: Pointer to a variable of type PduLengthType, into which the remaining size of the receive buffer after the copy operation is written [SWS_Com_00692].

Return Values and Properties

The function returns a status of type BufReq_ReturnType [SWS_Com_00692]:

• BUFREQ_OK: The data was successfully copied into the destination buffer [SWS_Com_00692].
• BUFREQ_E_NOT_OK: Copying of the data failed because an error occurred [SWS_Com_00692].

The interface has the service ID 0x44, is specified as reentrant, and is available via the header Com.h [SWS_Com_00692].

The synchronous and reentrant function Com_CopyTxData is called by lower-layer modules (such as transport protocols) to incrementally retrieve transmit data for segments (N-PDUs) of an I-PDU from the transmit buffer of the COM module [SWS_Com_00693].

Usage and Parameters

Each call provides the next part of the I-PDU data [SWS_Com_00693]:

• id: Identifies the I-PDU to be transmitted [SWS_Com_00693].
• info: Specifies the destination buffer via SduDataPtr and the number of bytes to be copied via SduLength. A length of 0 is permissible to transmit status changes via retry or to query the available data amount; in this case, SduDataPtr may be a NULL_PTR [SWS_Com_00693].
• retry: Confirms transmitted data or triggers retransmissions. If retry is a NULL_PTR, data may be removed from the buffer immediately after copying. If retry points to a RetryInfoType structure, TpDataState controls buffer retention: TP_CONFPENDING leaves data in the buffer for error recovery, TP_DATACONF confirms data copied before the call for deletion, and TP_DATARETRY copies previously read data again starting from offset TxTpDataCnt [SWS_Com_00693].
• availableDataPtr: Returns the remaining number of available bytes in the transmit buffer, which enables dynamic transport protocols (such as FrIsoTp), for example, to determine subsequent segment sizes [SWS_Com_00693].

Return Values and Error Handling

The function result signals the success of the buffer request via BufReq_ReturnType [SWS_Com_00693]:

• BUFREQ_OK: Data was completely copied into the destination buffer as requested [SWS_Com_00693].
• BUFREQ_E_BUSY: The requested amount of data is not available in the transmit buffer. No data is copied, and the lower-layer module may repeat the call at a later time [SWS_Com_00693].
• BUFREQ_E_NOT_OK: The request has failed; no data was copied [SWS_Com_00693].

use

The synchronous function Com_MainFunctionRx handles the internal receive processing of the AUTOSAR COM module for operations that are not processed directly in the execution context of APIs called by the PDU Router (PduR), such as Com_RxIndication [SWS_Com_00398]. It has neither input nor output parameters and returns no return value [SWS_Com_00398]. The declaration is made via header SchM_Com.h; the call context is therefore typically expected to occur periodically through the Schedule Manager (SchM) [SWS_Com_00398]. Question Q-48d121e36f62c6de (open)

Error handling and initialization

If the function is executed before module initialization by Com_Init or after a call to Com_DeInit, unlike most regular COM APIs, no error COM_E_UNINIT (0x02) is generated, because Com_MainFunctionRx is explicitly exempt from this [SWS_Com_00804]. Specific error or return codes do not exist for this interface [SWS_Com_00398].

Concurrency and multi-instance operation

Regarding execution context and reentrancy, the following specifications apply [SWS_Com_00398]:

• Reentrancy: The function is non-reentrant for the same instance, but may be called concurrently for different instances [SWS_Com_00398].
• Instance-specific manifestation: For each container ComMainFunctionRx defined in the ECU configuration, an independent function is implemented in the form Com_MainFunctionRx_<shortName>, where <shortName> corresponds to the short name of the configuration container [SWS_Com_00398].

Usage and Operation

The function Com_MainFunctionTx executes transmit activities of the AUTOSAR COM module that are not handled directly within the COM functions called by the RTE (such as Com_SendSignal) ([SWS_Com_00399]). Execution is synchronous. It has neither input, input/output, nor output parameters and returns no return value ([SWS_Com_00399]). The interface is declared via SchM_Com.h; Interpretation: Due to this header affiliation, the call context is likely to lie in schedule management (SchM). Question Q-c33cfcf81700bcc5 (open)

For each configured container of a Com Main Function Tx in the ECU configuration, a specific instance function according to the naming scheme Com_MainFunctionTx_<shortName> must be implemented, where <shortName> corresponds to the short name of the configuration container ([SWS_Com_00399]).

Concurrency and Limitations

Regarding reentrancy, Com_MainFunctionTx is designed reentrantly for different instances, but must not be called reentrantly for the same instance ([SWS_Com_00399]).

Error Handling and Initialization State

According to [SWS_Com_00804], calling COM services before initialization via Com_Init or after de-initialization via Com_DeInit regularly results in error COM_E_UNINIT (0x02). However, Com_MainFunctionTx is explicitly excluded from this and does not generate such an initialization error in these states ([SWS_Com_00804]).

The main function Com_MainFunctionRouteSignals (service ID 0x1a) serves in the AUTOSAR COM module as the central synchronous interface for signal forwarding ([SWS_Com_00400]). Its task is to call the signal gateway part of the COM module so that received signals designated for routing are forwarded to their configured destinations ([SWS_Com_00400]).

Call and Semantics

The parameterless C interface has the signature void Com_MainFunctionRouteSignals(void) ([SWS_Com_00400]). It is executed synchronously and has neither parameters for input, input/output, or output nor a return value ([SWS_Com_00400]). The declaration of the main function is provided via header file SchM_Com.h ([SWS_Com_00400]). Interpretation: Because of this provision via SchM_Com.h, the scheduled call in task context is likely to take place periodically by the BSW Scheduler (SchM). Question Q-0f0b57034d6d6bf1 (open)

Instantiation and reentrancy

For integration, naming, and concurrency, [SWS_Com_00400] defines the following binding requirements:

• Instance-specific implementation: For each instance of configuration container ComMainFunctionRouteSignals present in the ECU configuration, a dedicated function must be implemented according to the naming scheme Com_MainFunctionRouteSignals_<shortName> ([SWS_Com_00400]). Here, <shortName> corresponds to the short name of the respective configuration container.
• Reentrancy behavior: The function is reentrant for calls of different instances ([SWS_Com_00400]). For one and the same instance, however, it is explicitly non-reentrant and therefore must not be executed concurrently ([SWS_Com_00400]).

Callback function Com_CbkTxAck serves in module Com to notify about the successful transmission of a message [SWS_Com_00468]. It represents notification class 2 (notification class 2) and is called immediately after the successful transmission of the I-PDU containing the message concerned [SWS_Com_00468].

According to the specification, the following requirements apply to the call context and interface properties [SWS_Com_00468]:

• Signature and parameters: The callback function has signature void Com_CbkTxAck (void). It accepts neither input, input/output, nor output parameters and returns no return value [SWS_Com_00468].
• Synchronicity: The call is specified as synchronous (Synchronous) [SWS_Com_00468].
• Reentrancy: The reentrancy behavior is classified as don't care [SWS_Com_00468].
• Configuration: The interface is declared as configurable (configurable) [SWS_Com_00468]. Interpretation: The actual name of the callback function is presumably parameterized message- or signal-specifically in the configuration tool. Question Q-3670b7b04fd7c74c (open)

Specific error codes, error reactions, and messages to DET or DEM are not defined for this element in the specification [SWS_Com_00468]. Further ordering constraints with respect to other calls are also not listed [SWS_Com_00468].

Callback function Com_CbkTxErr is called synchronously when transmission is not possible because the associated I-PDU group is stopped [SWS_Com_00491]. It corresponds to notification class 4 according to the underlying specifications [SWS_Com_00491].

Call and Semantics

• Signature and parameters: The function has neither input, input/output, nor output parameters (void Com_CbkTxErr (void)) and returns no return value [SWS_Com_00491].
• Execution behavior: The call occurs synchronously (\"Synchronous\"), while \"don't care\" is specified for reentrancy [SWS_Com_00491].
• Availability: The callback interface is configurable (\"configurable\") [SWS_Com_00491].

Error Handling and Interaction

The function specifically serves to signal the error case of a prevented transmit request due to a stopped I-PDU group to the calling or upper layer [SWS_Com_00491]. Because no parameters are passed, the context of the affected signal or I-PDU is presumably specified via configuration or module-specific mappings. Question Q-d7153324d2eb2995 (open)

Usage and Call Context

Callback function Com_CbkTxTOut serves as a notification interface for the failure of a successful transmission. According to [SWS_Com_00554], it is called immediately after the deadline monitoring mechanism (deadline monitoring mechanism) has detected a transmission error of a message. The call is synchronous and corresponds to notification class 4. Because signature void Com_CbkTxTOut(void) has neither input nor return values, signaling to the upper layer is parameterless.

Concurrency and Configuration

Regarding reentrancy, the function is specified with don't care according to [SWS_Com_00554]. It is therefore presumably the responsibility of the invoked application software to take appropriate measures for thread safety if monitoring events can occur concurrently. Question Q-793a6c18d81de85e (open) Availability of the callback function is configurable in the communication module and is adapted to the respective monitoring requirements.

Error handling

In [SWS_Com_00554], no separate DET or DEM error messages and no return values for error acknowledgement are defined for Com_CbkTxTOut. Triggering the callback itself represents the error reaction to an exceeded transmission deadline.

Callback function Com_CbkRxAck serves in the AUTOSAR COM module as a configurable reception confirmation and represents notification class 1 according to [17] [SWS_Com_00555]. The COM module calls this callback routine immediately after a received message has been successfully deposited and stored in the designated receive message object [SWS_Com_00555].

Usage and Call Context

• Synchronous execution behavior: The function is specified as synchronous [SWS_Com_00555]. It is executed directly in the course of the storage operation, so that the calling context of the COM module waits for the execution of the callback.
• Parameters and return values: According to signature void Com_CbkRxAck (void), no input parameters, no input/output parameters, and no output parameters are passed [SWS_Com_00555]. The function also returns no return value to the calling module [SWS_Com_00555].
• Availability: The call mechanism is available to the system as a configurable interface [SWS_Com_00555].

Concurrency and Error Handling

The property \"don't care\" is defined for reentrancy [SWS_Com_00555]. This presumably means that the COM specification imposes no requirements on a reentrant invocation and protection mechanisms against concurrent access are the responsibility of the user. Question (open) Because neither return values nor specific error codes or error messages for DET or DEM are defined [SWS_Com_00555], any errors during processing presumably must be handled entirely locally within the callback function.

Usage and Semantics

Callback function Com_CbkRxTOut serves to notify about the absence of an expected message. According to [SWS_Com_00556], it is called immediately as soon as the module's deadline monitoring mechanism detects an error during message reception. This notification corresponds to reporting class 3 (\"notification class 3 of [17]\") and is available as a configurable interface [SWS_Com_00556].

The call occurs synchronously (Synchronous) without input parameters and without a return value (void Com_CbkRxTOut(void)) [SWS_Com_00556]. The function thus purely signals the timeout event itself to the calling receiver or the upper software layer without transmitting context data directly in the call.

Concurrency and Limitations

For the reentrancy of the function, don't care is specified in the specification [SWS_Com_00556]. Because the call takes place immediately and synchronously after error detection, the implementation of the callback routine presumably must be designed to execute with low blocking so as not to impermissibly delay the deadline monitoring of the COM module. Question Q-88055efc50f5843b (open)

Callback function Com_CbkInv notifies upper software layers about the reception of corrupted or invalid communication data in the AUTOSAR COM module [SWS_Com_00536]. It is called immediately after receiving an invalid signal or an invalid signal group and informs the receiver about the presence of an invalid signal value [SWS_Com_00536].

The interface has signature void Com_CbkInv(void), consequently takes no input parameters, and returns no return value to the caller [SWS_Com_00536]. The call occurs synchronously, while reentrancy behavior is stated as \"don't care\" in the specification [SWS_Com_00536]. Since no parameters identifying the affected signal are passed, identifier Com_CbkInv presumably serves as a configurable signature template for signal-specific notifications. Question Q-6e02e6bcf324eb93 (open)

Regarding integration and system behavior, the following boundary conditions apply:

• Provision of the function is configurable, allowing notification to be activated per signal or signal group as needed [SWS_Com_00536].
• Technically, the function corresponds to requirement SWS_Com_00680 for invalidation handling of received signals in the COM module [SWS_Com_00536].
• Specific error handling routines, error codes, or error messages to development or diagnostic modules such as DET or DEM are not identified for this interface [SWS_Com_00536].

The configurable callback function Com_CbkCounterErr serves to signal errors in I-PDU counter monitoring according to [SWS_Com_00726]. It is called immediately and synchronously by the AUTOSAR COM module when a counter value is detected in a received I-PDU that does not match the expected counter value. This enables early detection of sequence errors during message reception.

The interface has no return value (void) and passes three input parameters for error analysis when called ([SWS_Com_00726]):

• ComPduId (PduIdType): Identifier of the affected I-PDU in which the counter error occurred.
• ExpectedCounter (uint8): The counter value of the I-PDU expected by the COM module.
• ReceivedCounter (uint8): The counter value actually found in the received message.

Regarding concurrency, the reentrancy of the function is declared in the specification as “don't care” ([SWS_Com_00726]). Specific DET or DEM error messages are not specified for this interface in [SWS_Com_00726]. Since the callback function is defined as configurable, it is probably implemented in a higher layer such as the application in order to react to transmission errors or packet loss in an application-specific manner. Interpretation: Since the call takes place immediately and synchronously in the context of COM reception processing ([SWS_Com_00726]), the called routine should presumably not perform any blocking operations. Question Q-a745eb5416fc156b (open)

The callback function Com_CbkTxPrep serves as a notification that the signals or signal groups of a dedicated instance of Com_MainFunctionTx are now being prepared for transmission [SWS_Com_91013]. The execution of the function is synchronous to the calling instance [SWS_Com_91013]. According to its signature void Com_CbkTxPrep(void), it accepts neither input parameters nor input/output parameters or output parameters, and it has no return value [SWS_Com_91013].

The provision of the interface is available via configuration [SWS_Com_91013]. If the configuration parameter ComPreparationNotification is configured, the respective function Com_CbkTxPrep must be called within the associated MainFunctionTx [SWS_Com_00886]. In this case, a strict temporal ordering condition must mandatorily be observed: The call must take place completely before the actual processing of the I-PDUs is started within the Tx main function [SWS_Com_00886].

Regarding concurrency behavior and potential restrictions, Com_CbkTxPrep is specified as non-reentrant (Non Reentrant) [SWS_Com_91013]. The call context is strictly bound to the execution of the respective instance of MainFunctionTx [SWS_Com_91013]. Since the callback must be executed immediately before the start of I-PDU processing, the function is integrated synchronously into the corresponding transmission routine [SWS_Com_00886].

The function Com_RxIpduCallout is a configurable callout on the receiver side that serves to implement user-specific receive filtering mechanisms for I-PDUs [SWS_Com_00700]. Execution is synchronous, and with regard to reentrancy, the interface is specified as don't care [SWS_Com_00700].

The identifier as well as the data of the received PDU are passed to the call [SWS_Com_00700]:

• PduId: Identifier of the received I-PDU [SWS_Com_00700].
• PduInfoPtr: Pointer to a PduInfoType structure, which provides the length (SduLength) as well as a pointer to the payload (SduDataPtr) of the received I-PDU [SWS_Com_00700].

Regarding data provision, [SWS_Com_00816] requires that the module AUTOSAR COM forwards all data of the received I-PDU completely to Com_RxIpduCallout, exactly as provided by the PDU Router layer (PduR).

Via the boolean return value, the callout controls the subsequent processing of the I-PDU in the COM module [SWS_Com_00700]:

• true: The received I-PDU is processed further normally [SWS_Com_00700].
• false: The I-PDU is not processed further and is thus discarded [SWS_Com_00700].

Specific error codes, return code constants, or DET and DEM messages are not provided for this callout in the specification [SWS_Com_00700].

The function Com_TxIpduCallout serves as a configurable callout on the sender side and is called synchronously to perform user-specific preprocessing or transmission filtering of an outgoing I-PDU [SWS_Com_00346].

Parameters and Return Value

• PduId (in): Passes the identifier of the I-PDU to be transmitted [SWS_Com_00346].
• PduInfoPtr (inout): Contains the payload length (SduLength) as well as a pointer to the payload (SduDataPtr) of the I-PDU [SWS_Com_00346]. Through this, the I-PDU data can be inspected or modified before sending.
• Return value (boolean): Controls the further processing of the I-PDU [SWS_Com_00346]. A return value of true causes the regular transmission of the I-PDU, whereas false aborts any further processing and thus the transmission [SWS_Com_00346].

Concurrency and Configuration

The callout has service ID 0x29 and its reentrancy is defined as "don't care" in the specification [SWS_Com_00346]. Interpretation: Since reentrancy is unrestricted, calls are likely to occur in different task contexts depending on the triggering transmit request, which is why user-side implementations should be thread-safe for shared resources. Question Q-3ce35701879bb60c (open)

The enumeration type Com_StatusType defines the status value for the AUTOSAR COM module and is provided via the header file Com.h [SWS_Com_00819]. This type serves as the return value of the API service Com_GetStatus(), with which callers can query the current initialization and operating state of the communication module [SWS_Com_00819].

The specified value range of Com_StatusType distinguishes exactly two states [SWS_Com_00819]:

• COM_UNINIT: Indicates that the AUTOSAR COM module is not initialized or not usable [SWS_Com_00819]. This state mandatorily has the numerical value 0x00 (or value 0) and constitutes the mandatory default value immediately after a system reset [SWS_Com_00819].
• COM_INIT: Signals that the AUTOSAR COM module has been properly initialized and is therefore operational and usable [SWS_Com_00819].

For the calling software, the evaluation of this return value serves to verify the operational readiness of the communication module prior to its use [SWS_Com_00819]. As long as the service Com_GetStatus() returns the value COM_UNINIT, the COM module is considered not initialized or not usable [SWS_Com_00819]. Only when the status has the value COM_INIT is the module initialized and operational [SWS_Com_00819]. Further error codes or return values are not specified for this enumeration type [SWS_Com_00819].