The AUTOSAR COM module is derived from the OSEK communication protocol.
AUTOSAR COM来自OSEK通信协议
DM
Deadline Monitoring
超时监控
I-PDU
Interaction Layer Protocol Data Unit
交互层协议数据单元
L-PDU
Data Link Layer Protocol Data Unit
数据链路层协议数据单元
MDT
Minimum Delay Timer
最小延迟时间
PDU Router
The PDU Router is a module transferring I-PDUs from one module to another module. The PDU Router can be utilized for gateway operations and for internal routing purposes
The Com module mainly implements the functions of encapsulating and parsing Signals in I-PDUs, provides Signal-based sending and receiving interfaces for the RTE layer, realizes Signal-based gateway functions, implements different sending modes of PDUs, as well as functions such as Signal filtering and Update bit.
As shown in the [Module Hierarchy Diagram], the Com module is located in the Communication Service Layer of the AUTOSAR architecture, with the PduR module as its lower-layer module and the RTE as its upper-layer module.
The Com module implements enable control based on I-PDU Group and enable control for reception timeout detection. According to the inclusion relationship between I-PDUs and I-PDU Groups, it indirectly realizes the communication enable control for each I-PDU and the enable control for reception timeout detection of Rx I-PDUs.
The encapsulation and parsing of signals are the core functions of the Com module. It encapsulates the transmitted signals into the associated Tx IPdu data according to the configuration information of each signal, and parses the received signals from the Rx IPdu data. This includes the transmission and reception of non-dynamic length type signals, dynamic length type signals, GroupSignals, and byte-aligned SignalGroups.
Com模块为RTE/应用层提供了完整的基于Signal/SignalGroup的收发接口。
The Com module provides the RTE/application layer with a complete set of sending and receiving interfaces based on Signal/SignalGroup.
The Com module implements two types of IPdu transmission and reception methods based on data flow: the IF mode and the TP mode. The IF mode is usually used for IPdus with “small data length”, while the TP mode is generally applied to IPdus with “large data length”. Here, the “data length” is defined relative to the transmission bus. For example, the CAN bus is 8 bytes, CANFD is 64 bytes, and ETH can reach more than 1000 bytes. Among them, the transmission of IF IPdu is further divided into two types: Direct and TriggerTransmit. The transmission timing of the former is determined by Com, while that of the latter is decided by the lower-layer module.
From the perspective of transmission timing, Tx IPdu is further divided into four modes: PERIODIC, DIRECT, MIXED, and NONE. The NONE mode is usually configured with TriggerTransmit, or by calling Com_TriggerIPDUSend/Com_TriggerIPDUSendWithMetaData to implement the transmission of IPdu.
The Com module implements a timeout monitoring function based on Signal/SignalGroup. For transmission, it implements a timeout notification mechanism; for reception, it implements two mechanisms: timeout notification and timeout replacement.
Transmission timeout monitoring: Monitors the period from when a transmission request is made to when the transmission of the IPdu it belongs to is successful. The IPdu timeout threshold is the minimum timeout value configured for the Signal/SignalGroup that requested the transmission. When a transmission timeout occurs, the upper-layer module is notified.
Reception timeout monitoring: Monitors the time period between two successful receptions of signal values. The timeout threshold for a Signal/SignalGroup is determined according to its respective configuration parameters. When a timeout occurs, a notification is sent, or the received signal value is replaced with an initial value or a substitute value.
The Com module implements a mechanism for filtering based on the signal values of signals. Although the filtering algorithm for transmitting and receiving signals is the same, the purposes of filtering are completely different.
For transmitted Signals/GroupSignals, the result of the filtering algorithm only determines whether the transmitting IPdu selects ComTxModeTrue or ComTxModeFalse for message transmission, and the signal itself will not be discarded.
The Com module implements an Update Bit mechanism based on Signal/SignalGroup to identify whether a signal has been updated (a signal update does not necessarily mean a change in the signal value).
A Signal/SignalGroup determines whether to support the Update mechanism through the configuration parameter ComUpdateBitPosition. The Update Bit itself occupies one bit in the IPdu, where a value of 1 indicates that the corresponding Signal/SignalGroup has been updated, and a value of 0 indicates that the corresponding Signal/SignalGroup has not been updated.
For transmitted signals, when a request to send a Signal/SignalGroup is made, the Com module sets its Update Bit to 1, indicating that the signal has been updated. The timing for clearing (setting to 0) all Update Bits in the transmitted IPdu is determined by the configuration parameter ComTxIPduClearUpdateBit of the ComTxIPdu.
For received signals, further reception operations are only performed if the Update Bit of the Signal/SignalGroup is detected as 1; otherwise, the signal is discarded.
The signal gateway in Com only targets Signals and GroupSignals. The R19_11 standard no longer supports gateways based on SignalGroups. The signal gateway supports not only 1:1 but also 1:N.
For GwSource signals and GwDestination signals, their signal types and signal lengths must be consistent. The GwSource signal is associated with the Rx IPdu, and the GwDestination signal is associated with the Tx IPdu.
注：TP Pdu中的Signal/Group Signal不支持信号网关。
Note: Signals/Group Signals in TP Pdu do not support the signal gateway.
The signal gateway routing is implemented through configuring ComGwMapping. The GwSource signal can be configured in two ways: by configuring ComGwSourceDescription and by configuring ComGwSignal.
To provide load distribution among multiple partitions (cores), different parts of the communication stack can be allocated to different partitions. Components of different network types such as FlexRay, CAN, and Ethernet can be assigned to separate partitions (cores).
为了支持上述灵活的分配，减少分区间的通信（从而潜在的减少跨分区同步带来的阻塞），COM 模块可以按照网络类型创建不同的 MainFunction（每个分区至少一个）。在具体的 MainFunction 中仅处理与该网络类型相关的 PDU，接收和发送将保持在单个网络范围内（即在单个分区中），因此不需要考虑跨分区同步的问题。唯一的例外是信号网关，当信号网关的源和目的PDU不在同一个分区时，COM模块提供跨分区的数据一致性保护。每个 MainFunction 都拥有独立的 Time Base。
To support the above flexible allocation and reduce inter-partition communication (thereby potentially reducing blocking caused by cross-partition synchronization), the COM module can create different MainFunctions according to network types (at least one per partition). Each specific MainFunction only processes PDUs related to that network type, and reception and transmission are kept within a single network scope (i.e., within a single partition), thus eliminating the need to consider cross-partition synchronization. The only exception is the signal gateway: when the source and destination PDUs of the signal gateway are not in the same partition, the COM module provides cross-partition data consistency protection. Each MainFunction has an independent Time Base.
ComIPdu is associated with specific ComMainFunctionRx/ComMainFunctionTx through ComIPduMainFunctionRef. ComMainFunctionRouteSignalsRef is only used on the ComIPdu where the target signal of the signal gateway is located. ComMainRxPartitionRef/ComMainTxPartitionRef/ComMainRouteSignalsPartitionRef respectively indicate the partition in which the ComMainFunction instance runs. If partition information is configured, the partition where ComMainFunction is located must be consistent with the partition of the Pdu (EcucPduDefaultPartitionRef) associated with ComIPdu. It is emphasized here that if a transmitting IPDU (IPDU or the signals and group signals contained in the IPDU) is used for the signal gateway, it needs to be configured with ComIPduMainFunctionRef associated to ComMainFunctionTx and ComMainFunctionRouteSignalsRef at the same time, and the partitions must be consistent.
If the Com module is configured with ComIpduGroup, it must be associated with at least one IPDU, and the partitions of the IPDUs associated with the same ComIpduGroup must be consistent.
The partition information of IPDU is configured and implemented in the ECUC module. After the Com module is configured and verified successfully, right-click “Synchronize Module” in the ECUC module and select the Com module to synchronize, so that the partition information of the Com module can be synchronized to the IPDU of the ECUC module.
The code generator will generate a function for each ComMainFunction (declared in SchM_Com.h). Each ComMainFunction instance and API interface needs to be placed in the correct partition to be called during integration. It is recommended to enable the ComConfigurationUseDet configuration during the development phase. If there is an unreasonable partition call, a Det error can be reported.
As the core file of the Com module, it implements all external interfaces of the Com module, as well as the local functions, local macro definitions, and local variable definitions that are necessary for realizing the functions of the Com module.
Com_Internal.h
实现Com模块内部函数的声明
Implement the declaration of internal functions of the Com module
Com_Internal.c
实现Com模块公共内部函数的定义
Implement the definition of public internal functions of the Com module
Com_GwInternal.c
实现Com模块信号网关功能内部函数的定义
Implement the definition of internal functions for the Com module’s signal gateway functionality
Com_RxInternal.c
实现Com模块信号接收内部函数的定义
Implement the definition of internal functions for signal reception in the Com module
Com_TxInternal.c
实现Com模块信号发送内部函数的定义
Implement the definition of internal functions for signal transmission in the Com module
Implement the definitions of external/internal types, including types defined by the AUTOSAR standard, as well as structure types for PB/PC configuration parameters and internal runtime structure types.
Com_Cbk.h
实现Com模块全部回调函数的声明
Implement the declarations of all callback functions of the Com module
Within this API, the upper layer module (called module) shall check whether the available data fits into the buffer size reported by PduInfoPtr->SduLength. If it fits, it shall copy its data into the buffer provided by PduInfoPtr->SduDataPtr and update the length of the actual copied data in PduInfoPtr->SduLength. If not, it returns E_NOT_OK without changing PduInfoPtr.
Sync/Async
TRUE
Reentrancy
Reentrant for different PduIds. Non reentrant for the same PduId.
Parameters
Dir
Name
Description
[in]
TxIpduId
ID of the SDU that is requested to be transmitted.
[inout]
PduInfoPtr
Contains a pointer to a buffer (SduDataPtr) to where the SDU data shall be copied, and the available buffer size in SduLengh.On return, the service will indicate the length of the copied SDU data in SduLength.
Return type
Std_ReturnType
Return values
Name
Description
E_OK
SDU has been copied and SduLength indicates the number of copied bytes.
E_NOT_OK
No SDU data has been copied. PduInfoPtr must not be used since it may contain a NULL pointer or point to invalid data.
This function is called at the start of receiving an N-SDU. The N-SDU might be fragmented into multiple N-PDUs (FF with one or more following CFs) or might consist of a single N-PDU (SF).
Sync/Async
TRUE
Reentrancy
Reentrant
Parameters
Dir
Name
Description
[in]
id
Identification of the I-PDU.
[in]
info
Pointer to a PduInfoType structure containing the payload data (without protocol information) and payload length of the first frame or single frame of a transport protocol I-PDU reception. Depending on the global parameter MetaDataLength, additional bytes containing MetaData (e.g. the CAN ID) are appended after the payload data, increasing the length accordingly. If neither first/single frame data nor MetaData are available, this parameter is set to NULL_PTR.
[in]
TpSduLength
Total length of the N-SDU to be received.
[out]
bufferSizePtr
Available receive buffer in the receiving module. This parameter will be used to compute the Block Size (BS) in the transport protocol module.
Return type
BufReq_ReturnType
Return values
Name
Description
BUFREQ_OK
Connection has been accepted. bufferSizePtr indicates the available receive buffer; reception is continued.If no buffer of the requested size is available, a receive buffer size of 0 shall be indicated by bufferSizePtr.
BUFREQ_E_NOT_OK
Connection has been rejected; reception is aborted. bufferSizePtr remains unchanged.
BUFREQ_E_OVFL
No buffer of the required length can be provided; reception is aborted. bufferSizePtr remains unchanged.
This function is called to provide the received data of an I-PDU segment (N-PDU) to the upper layer. Each call to this function provides the next part of the I-PDU data. The size of the remaining data is written to the position indicated by bufferSizePtr.
Sync/Async
TRUE
Reentrancy
Reentrant
Parameters
Dir
Name
Description
[in]
id
Identification of the received I-PDU.
[in]
info
Provides the source buffer (SduDataPtr) and the number of bytes to be copied (SduLength). An SduLength of 0 can be used to query the current amount of available buffer in the upper layer module. In this case, the SduDataPtr may be a NULL_PTR.
[out]
bufferSizePtr
Available receive buffer after data has been copied.
This function is called to acquire the transmit data of an I-PDU segment (N-PDU). Each call to this function provides the next part of the I-PDU data unless retry->TpDataState is TP_DATARETRY. In this case the function restarts to copy the data beginning at the offset from the current position indicated by retry->TxTpDataCnt. The size of the remaining data is written to the position indicated by availableDataPtr.
Sync/Async
TRUE
Reentrancy
Reentrant
Parameters
Dir
Name
Description
[in]
id
Identification of the transmitted I-PDU.
[in]
info
Provides the destination buffer (SduDataPtr) and the number of bytes to be copied (SduLength). If not enough transmit data is available, no data is copied by the upper layer module and BUFREQ_E_BUSY is returned. The lower layer module may retry the call. An SduLength of 0 can be used to indicate state changes in the retry parameter or to query the current amount of available data in the upper layer module. In this case, the Sdu DataPtr may be a NULL_PTR.
[in]
retry
This parameter is used to acknowledge transmitted data or to retransmit data after transmission problems.
[out]
availableDataPtr
Indicates the remaining number of bytes that are available in the upper layer module’s Tx buffer. availableDataPtr can be used by TP modules that support dynamic payload lengths (e.g. FrIsoTp) to determine the size of the following CFs.
Return type
BufReq_ReturnType
Return values
Name
Description
BUFREQ_OK
Data has been copied to the transmit buffer completely as requested.
BUFREQ_E_BUSY
Request could not be fulfilled, because the required amount of Tx data is not available. The lower layer module may retry this call later on. No data has been copied.
This service initializes internal and external interfaces and variables of the AUTOSAR COM module layer for the further processing. After calling this function the inter-ECU communication is still disabled.
Sync/Async
TRUE
Reentrancy
Non Reentrant
Parameters
Dir
Name
Description
[in]
config
Pointer to the AUTOSAR COM module’s configuration data.
This service stops the inter-ECU communication. All started I-PDU groups are stopped and have to be started again, if needed, after Com_Init is called. By a call to Com_DeInit the AUTOSAR COM module is put into an not initialized state.
The service Com_SendSignal updates the signal(include group signal) object identified by SignalId with the signal referenced by the SignalDataPtr parameter.
Sync/Async
FALSE
Reentrancy
Non Reentrant for the same signal. Reentrant for different signals.
Parameters
Dir
Name
Description
[in]
SignalId
Id of signal to be sent.
[in]
SignalDataPtr
Reference to the signal data to be transmitted.
Return type
uint8
Return values
Name
Description
E_OK
service has been accepted
COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped (or service failed due to development error)
COM_BUSY
in case the TP-Buffer is locked for large data types handling
Com_ReceiveDynSignal copies the data of the signal identified by SignalId to the location specified by SignalDataPtr and stores the length of the dynamical length signal at the position given by the Length parameter.
Sync/Async
TRUE
Reentrancy
Reentrant
Parameters
Dir
Name
Description
[in]
SignalId
Id of signal to be received.
[in]
SignalDataPtr
Reference to the location where the received signal data shall be stored
[inout]
Length
in: maximum length that could be received;out: length of the dynamic length signal
Return type
uint8
Return values
Name
Description
E_OK
service has been accepted
E_NOT_OK
in case the Length (as in-parameter) is smaller than the received length of the dynamic length signal
The service Com_SendSignalGroupArray copies the content of the provided SignalGroupArrayPtr to the associated I-PDU. The provided data shall correspond to the array representation of the signal group.
Sync/Async
FALSE
Reentrancy
Reentrant
Parameters
Dir
Name
Description
[in]
SignalGroupId
Id of signal group to be sent.
[in]
SignalGroupArrayPtr
Reference to the signal group array.
Return type
uint8
Return values
Name
Description
E_OK
service has been accepted
COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped
COM_BUSY
in case the TP-Buffer is locked for large data types handling
The service Com_ReceiveSignalGroupArray copies the received signal group array representation from the PDU to the location designated by SignalGroupArrayPtr.
Sync/Async
TRUE
Reentrancy
Reentrant
Parameters
Dir
Name
Description
[in]
SignalGroupId
Id of signal group to be sent.
[in]
SignalGroupArrayPtr
Reference to the signal group array.
Return type
uint8
Return values
Name
Description
E_OK
service has been accepted
COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group was stopped
COM_BUSY
in case the TP-Buffer is locked for large data types handling
The service Com_InvalidateSignalGroup invalidates all group signals of the signal group with the given SignalGroupId by setting their values to their configured ComSignalDataInvalidValues.
Sync/Async
FALSE
Reentrancy
Reentrant
Parameters
Dir
Name
Description
[in]
SignalGroupId
Id of signal group to be invalidated.
Return type
uint8
Return values
Name
Description
E_OK
service has been accepted
COM_SERVICE_NOT_AVAILABLE
corresponding I-PDU group is stopped, no ComSignalDataInvalidValue is configured for any of the group signals
By a call to Com_TriggerIPDUSendWithMetaData the AUTOSAR COM module updates its internal metadata for the I-PDU with the given ID by copying the metadata from the given position and with respect to the globally configured metadata length of the I-PDU. Then the I-PDU is triggered for transmission.
Sync/Async
TRUE
Reentrancy
Non Reentrant
Parameters
Dir
Name
Description
[in]
PduId
The I-PDU-ID of the I-PDU that shall be triggered for sending
[in]
MetaData
A pointer to the metadata for the triggered send-request
Return type
Std_ReturnType
Return values
Name
Description
E_OK
I-PDU was triggered for transmission
E_NOT_OK
I-PDU is stopped, the transmission could not be triggered
The service Com_SwitchIpduTxMode sets the transmission mode of the I-PDU referenced by PduId to Mode. In case the transmission mode changes, the new mode shall immediately be effective. In case the requested transmission mode was already active for this I-PDU, the call will have no effect.
Sync/Async
TRUE
Reentrancy
Reentrant for different PduIds. Non reentrant for the same PduId.
Parameters
Dir
Name
Description
[in]
PduId
Id of the I-PDU of which the transmission mode shall be changed.
This function performs the processing of the AUTOSAR COM module’s receive processing that are not directly handled within the COM’s functions invoked by the PDU-R, for example Com_RxIndication.
Sync/Async
TRUE
Reentrancy
Reentrant for different instances. Non reentrant for the same instance.
This function performs the processing of the AUTOSAR COM module’s transmission activities that are not directly handled within the COM’s function invoked by the RTE, for example Com_SendSignal.
Sync/Async
TRUE
Reentrancy
Reentrant for different instances. Non reentrant for the same instance.
MainFunction association: ComIPduMainFunctionRef = ComMainFunctionRx. When there are multiple ComMainFunctionRx instances, all RxIpdu must be associated with ComMainFunctionRx; otherwise, no association is required.
关联ComIPduSignalGroupRef = ComSignalGroup（如果存在）
Associated ComIPduSignalGroupRef = ComSignalGroup (if it exists)
关联ComIPduSignalRef = ComIPduSignal（如果存在）
Associated ComIPduSignalRef = ComIPduSignal (if it exists)
MainFunction association: ComIPduMainFunctionRef = ComMainFunctionTx. When there are multiple ComMainFunctionTx instances, all TxIpdu must be associated with ComMainFunctionTx; otherwise, no association is required.
MainFunction association: ComMainFunctionRouteSignalsRef = ComMainFunctionRouteSignals. If this IPdu or the contained Signal/GroupSignal is used for the signal gateway, and there are multiple ComMainFunctionRouteSignals instances, this TxIpdu must be associated; otherwise, no association is required.
关联ComIPduSignalGroupRef = ComSignalGroup（如果存在）
Associated ComIPduSignalGroupRef = ComSignalGroup (if it exists)
关联ComIPduSignalRef = ComIPduSignal（如果存在）
Associated ComIPduSignalRef = ComIPduSignal (if it exists)
Transmission filtering can be configured in TxSignal, TxGroupSignal, and ComGwDestinationDescription. The prerequisite for configuring filtering is that it must be configured simultaneously, as shown in [TxModeTrueFalse] in the figure:
Invalid value reception notification: The invalid value ComSignalDataInvalidValue must be configured first before ComDataInvalidAction can be configured. If ComDataInvalidAction = NOTIFY, then the ComInvalidNotification (invalid value notification) can be configured. If ComDataInvalidAction = REPLACE, it means that after receiving an invalid value, the received value will be replaced with the initial value.
Invalid value transmission notification: Similar to the invalid value reception notification, but the difference is that transmission will not perform invalid value replacement and only has a notification function. Sending invalid values can be implemented using API functions.As shown in: [RxInvalid]
Reception timeout monitoring notification: A non-zero ComTimeout must be configured. ComFirstTimeout can be configured as required. The reception timeout notification (ComTimeoutNotification) is independent of the reception notification. The reception timeout action (ComRxDataTimeoutAction) includes: NONE (no processing), REPLACE (replace with initial value), and SUBSTITUTE (replace with ComTimeoutSubstitutionValue).As shown in: [RxTimeout]
Transmission timeout monitoring notification: A non-zero ComTimeout must be configured. The transmission timeout notification (ComTimeoutNotification) can be configured as required and is independent of the transmission notification. The timeout action (ComRxDataTimeoutAction) is set to NONE (no processing).As shown in: [TxTimeout]
开源小满EasyXMen
