SNIP_CLASSIC_CANTP_SECTION_7_3_7_Concurrent_connection

7.3.7 Concurrent connection The CAN Transport Layer is able to manage several connections simultaneously (e.g. a UDS and an OBD request can be received at the same time). [SWS_CanTp_00096] Upstream requirements: SRS_Can_01066 ⌈The CanTp module shall support several connections simultaneously.⌋ [SWS_CanTp_00120] Upstream requirements: SRS_Can_01066 ⌈It shall be possible to configure concurrent connections in the CanTp module.⌋ [SWS_CanTp_00285] ⌈The connection channels are only destined for CAN TP internal use, so they are not accessible externally.⌋ [SWS_CanTp_00286] ⌈All the necessary information (Channel number, Timing parameter . . . ) is configured inside the CAN Transport Layer module.⌋ [SWS_CanTp_00121] Upstream requirements: SRS_Can_01066 ⌈Each N-SDU is statically linked to one connection channel. This connection channel represents an internal path, for the transmission or receiving of the N-SDU. A connection channel is attached to one or more N-SDU.⌋ [SWS_CanTp_00122] Upstream requirements: SRS_Can_01066 ⌈Each connection channel is independent of the other connection channels. This means that a connection channel uses its own resources, such as internal buffer, timer, or state machine.⌋ [SWS_CanTp_00190] ⌈The CanTp module shall route the N-SDU through the correctly configured connection channel.⌋ [SWS_CanTp_00287] ⌈The CanTp module shall not accept the receiving or the transmission of N-SDU with the same identifier in parallel, because otherwise the received frames cannot be assigned to the correct connection. When only specific connections (without MetaData) are used, this requirement is enforced by the configuration, because each N-SDU is linked to only one connection channel.⌋ If a user wants to dedicate a specific connection channel to only one N-SDU, they should assign this connection channel to one N-SDU only during the configuration process. [SWS_CanTp_00288] ⌈If a connection channel is assigned to multiple N-SDUs, then resources are shared between different N-SDUs, and the CAN Transport Layer will reject transmission or abort receiving, if no free connection channels are available.⌋ [SWS_CanTp_00289] ⌈The number of connection channels is not directly configurable. It will be determined by the configuration tools during the configuration process, by analyzing the N-SDU/Channel routing table.⌋ [SWS_CanTp_00123] Upstream requirements: SRS_Can_01066 ⌈If the configured transmit connection channel is in use (state CANTP_TX_PROCESSING), the CanTp module shall reject new transmission requests linked to this channel. To reject a transmission, CanTp returns E_NOT_OK when the upper layer asks for a transmission with the CanTp_Transmit() function.⌋ [SWS_CanTp_00124] Upstream requirements: SRS_Can_01066 ⌈When an SF or FF N-PDU without MetaData is received, and the corresponding connection channel is currently receiving the same connection (state CANTP_RX_PROCESSING, same N_AI), the CanTp module shall abort the reception in progress and shall process the received frame as the start of a new reception. When an SF or FF N-PDU without MetaData is received for another connection (different N_AI) on an active connection channel, the SF or FF shall be ignored.⌋ [SWS_CanTp_00337] ⌈When an SF or FF N-PDU with MetaData (indicating a generic connection) is received, and the corresponding connection channel is currently receiving, the SF or FF shall be ignored.⌋ [SWS_CanTp_00248] ⌈When a Tx N-PDU is used by two or more different connections on different channels, access to this N-PDU shall be serialized by using the TxConfirmation. An Rx N-PDU can only be used on two or more different connection channels if extended or mixed addressing is used in relation with this N-PDU or when it has MetaData (and thus belongs to a generic connection).⌋ Note: CAN FD and CAN frames will be mapped to different PDUs by LSduR depending on the frame format (CAN FD or CAN 2.0). Therefore, it is possible to distinguish between CAN FD and classic CAN communication.