一、简介
该规范描述了AUTOSAR基本软件模块CAN接口的功能，API和配置。
如图1.1所示，CAN接口模块位于低层CAN设备驱动程序（CAN驱动程序[1]和收发器驱动程序[2]）与上层通信服务层（即CAN状态管理器[3]，
CAN网络管理[ 4]，
CAN传输协议[5]，PDU路由器[6]）。 它代表用于上层通信层的CAN驱动程序服务的接口。
CAN接口模块提供了一个独特的接口来管理不同的CAN硬件设备类型，例如定义的ECU硬件布局所使用的CAN控制器和CAN收发器。
因此，多个状态内部和外部CAN控制器CAN收发器可以由CAN State Managers模块基于以下功能来控制：
物理CAN通道相关视图。
CAN接口模块由所有独立于CAN硬件的任务组成，这些任务属于相应ECU的CAN通信设备驱动程序。 这些功能一次在CAN接口模块中实现，
因此基础的CAN设备驱动程序仅专注于对相应特定CAN硬件设备的访问和控制。
CanIf满足PDU路由器和AUTOSAR COM堆栈的上层通信模块的主控制流和数据流要求：传输请求处理，传输确认/接收指示/错误通知以及CAN控制器的启动/停止，从而唤醒/参与在网络上。它的数据
处理和通知API基于CAN L-SDU，而用于控制和模式处理的API提供了与CAN控制器相关的视图。在发送请求的情况下，CanIf使用相应的参数完成L-PDU的传输，并通过适当的CanDrv将CAN L-PDU中继到CAN控制器。在接收时，CanIf将接收到的L-PDU作为LSDU分发到上层。接收L-SDU与上层之间的分配
是静态配置的。在发送确认时，CanIf负责通知有关成功发送的上层。
CAN接口模块提供对CAN驱动程序和CAN收发器驱动程序服务的CAN通信抽象访问，以控制和监视CAN网络。 CAN接口将状态更改请求从CAN状态管理器向下转发到下层CAN设备驱动程序，然后向上转发
CAN驱动程序/ CAN收发器驱动程序事件由CAN接口模块转发到例如相应的NM模块。
1.1 一般功能
初始化
传输请求服务
传送确认服务
接待指示服务
控制器模式控制服务
PDU模式控制服务
CanIf的可能应用：
1.中断模式
CanDrv处理由CAN控制器触发的中断。 CanIf（基于事件）在事件发生时得到通知。在这种情况下，可以在CanDrv中的相应ISR中调用相关的CanIfservices。
2.轮询模式
CanDrv由SchM触发并执行后续过程（PollingMode）。在这种情况下，Can_MainFunction_ <Write / Read / BusOff / Wakeup /
必须在定义的时间间隔内定期调用Transceiver>（）。
CanDrv通知CanIf有关在一个CAN控制器中发生的事件（接收，发送，BusOff，发送取消，超时）的消息，
等同于中断驱动的操作。 CanDrv负责更新属于CANController中发生的事件的相应信息，例如接收L-PDU。
3.混合模式：中断和轮询驱动的CanDrv
根据使用的CAN控制器，可以将功能分为中断驱动和轮询驱动两种操作模式。
示例：轮询驱动的FullCAN接收和中断驱动的BasicCAN接收，轮询驱动的发送和中断驱动的接收等 本规范描述了唯一的接口，该接口对所有三种类型的操作模式均有效。 总而言之，无论是在中断，任务级别还是混合处理任何事件时，CanIf的工作方式都相同。 唯一的区别是呼叫上下文以及通知中断的方式：抢占式或合作式。 所有
服务根据配置执行。
以下段落描述了CanIf的功能。
CanIf应避免直接访问特定于硬件的通信
标题，并只能通过CanDrv接口服务进行进行访问。C
（SRS_Can_01001）[SWS_CANIF_00023]的基本原理：CanIf仍独立于硬件，因为使用HOH参数调用了CanDrv接口，该接口从特定的CAN硬件样本属性中提取。
这些逻辑上可以链接到整个硬件对象池（多路替代的硬件对象），因此可以通过一个HTH进行交换。CanIf将使用两种类型的HOH来访问Can-
驱动
硬件传输手柄（HTH）和
硬件接收句柄（HRH）。
HRH的定义：HRH应该是一个引用
CAN控制器邮箱的逻辑硬件接收对象。 C（）
HRH将使CanIf能够使用所引用的接收单元的BasicCAN或FullCAN接收方法，并向目标上层模块指示接收到的L-SDU。 C（）
如果HRH引用为BasicCAN接收配置的接收单元，则应在CanIf中启用软件过滤。 C（）
如果使用多个HRH，则每个HRH至少应属于一个
Rx L-SDU的单个或固定组（CanRxPduIds）。
HTH的定义：HTH应该是引用
CAN Controller邮箱的逻辑硬件传输对象
HTH将使CanIf能够使用BasicCAN或FullCAN
参考传输单元的传输方法，并确认传输到目标上层模块的L-SDU
每个CanIf Tx L-PDU应该静态分配给一个
配置时可以使用CanIfBufferCfg配置容器（请参见CanIfTxPduBufferRef）。
CanIf Tx L-PDU不引用HTH，而是Can-IfBufferCfg，后者又引用HTH。
如果使用多个HTH，则每个HTH都应属于一个
或固定组的Tx L-PDU（CanTxPduIds）。
CanIf应当能够将一个CanDrv的所有HRH和HTH用作从零开始的通用单个编号区域。
专用的HRH和HTH源自CanDrv的配置集。 HTH / HRH在编号区域和“硬件对象”中的定义取决于CanDrv。
静态L-PDU
CanIf提供对上层CAN L-SDU相关数据的常规访问。 属性
下表中的表示为配置参数，并且
在第10章中指定：
CanIf只能将每个L-PDU分配给一个CAN控制器。 因此，禁止将单个L-PDU分配给多个CAN控制器。
CanIf只能将每个L-PDU分配给一个CAN控制器。因此，禁止将单个L-PDU分配给一个以上的CAN控制器。[SWS_CANIF_00046]的说明：使用此关系是为了确保在发送确认和接收指示事件时进行正确的LSDU调度。这样，CanIf能够从L-PDU识别CAN控制器。
CanIf支持激活和停用属于一个CAN控制器的所有L-PDU进行发送和接收（请参阅7.19.2，
请参见CanIf_SetPduMode（），[SWS_CANIF_00008]）。有关L-PDU模式控制，请参阅第7.19节。
每个L-PDU与一个上层模块相关联，以确保在接收，传输确认和数据访问期间进行正确的调度。每个上层模块可以使用L-PDU来同时服务于不同的CAN控制器。
根据为整个AUTOSAR通信堆栈定义的PDU体系结构（请参见[7，分层的软件体系结构]），L-PDU的使用分为两种不同的方式：
1，对于传输请求和传输/接收轮询API，上层模块使用CanIf定义的L-SDU ID（CanTxPduId / CanRxPduId）作为参数。
2.对于由CanIf在上层模块调用的所有回调API，CanIf会将每个上层模块定义的目标PduId传递为参数。原理是，呼叫者必须使用被呼叫者的已定义目标L-PDU / L-SDU ID。
如果未执行开机初始化，并且上层执行了向CanIf的发送请求，则不会将L-SDU发送到下层，并且应调用DET。因此，无法在网络上传输未初始化的数据。 L-PDU / L-SDU发送功能的行为在第8.3.6节中详细说明。
动态L-PDU
CanIf应该支持使用CanIfRxPduCanIdMask过滤传入消息的能力。 在将CanIfRxPduCanIdMask应用于两个ID之后，应通过比较传入的CanId与存储的CanIfRxPduCanId来完成过滤。
应该在过滤不带掩码的常规CanId之后进行此操作，以允许对属于掩码或基于CanId的范围定义的范围内的某些CanId进行单独处理。
另外，当CanId驻留在L-SDU的元数据中时，应支持DYNAMIC Tx和Rx L-SDU。
在动态L-SDU的传输过程中，定义CanIfTxPduCanIdMask时，必须使用此掩码将通过元数据提供的CanId的可变部分与CanId合并。 没有CanIfTxPduCanIdMask且没有CanIfTxPdu-
已配置CanId，则MetaData应直接用作CanId。
在接收动态L-SDU的过程中，接收到的CanId必须放在L-SDU元数据中。 元数据的内容与CanIfRxPduCanId- Mask参数无关。
[SWS_CANIF_00844] d CanIf将支持动态L-PDU，其中CanId或CanId的相关部分位于L-SDU的元数据中。 C（）
物理频道视图
CanIf应该提供一个ControllerId，它抽象
来自不同CanDrv实例的不同控制器。 CanIf中ControllerId的范围应以“ 0”开头。 它应该可以通过CANIF_CTRL_ID进行配置（请参见ECUC_CanIf_00647）
CanIf必须提供一个TransceiverId，该抽象
来自不同CanTrcv实例的不同收发器。 CanIf中的TransceiverId范围应以“ 0”开头。 它可以通过以下方式配置
CanIf支持多个物理CAN通道。 CanSm必须区分这些以进行网络控制。 CanIf API为多个基础物理CAN通道提供请求和读取控制
CAN硬件单元组合了一个或多个相同类型的CAN控制器模块，这些模块可以位于芯片上，也可以作为外部独立设备使用。 每个CAN硬件单元均由相应的CanDrv提供服务。
如果使用不同类型的CAN控制器，则还必须将不同类型的CanDrv与统一的API应用于CanIf。 CanIf在配置时收集有关CAN控制器及其硬件对象的数量和类型的信息。
这允许使用HOH从上层模块透明且独立于硬件访问CAN控制器（请参见第7.2节“硬件对象句柄”和第7.24节“多CAN驱动程序支持”）。 图7.4显示了一个CAN硬件单元，它由连接到两个物理通道的两个相同类型的CAN控制器组成：
BasicCAN和FullCAN接收
CanIf区分BasicCAN和FullCAN处理，以激活软件接受过滤。
用于FullCAN操作的CAN邮箱（硬件对象）仅允许发送或接收单个CanId。 因此，一个硬件对象的BasicCAN操作使得能够发送或接收一系列CanId。
用于配置的BasicCAN接收的硬件接收对象能够接收一系列的CanId，这些CanId通过其硬件接受过滤器。 此范围可能超出此HRH接收的预定义Rx L-PDU列表。
因此，CanIf随后将执行软件过滤以仅传递Rx LPDU的预定义列表
到相应的上层模块。 有关更多详细信息，请参见第7.20节“软件接收过滤器”。
BasicCAN和FullCAN操作之间的主要区别在于需要一种软件接受过滤机制
CanIf将执行软件验收过滤器
从[SWS_CANIF_00469]中获取由回调函数CanIf_RxIndication（）传递的HRH
BasicCAN和FullCAN对象可以在单个配置设置中共存。 如果基础CAN控制器提供了多个BasicCAN和FullCAN接收对象，则可以使用。
如果CanIf收到L-PDU（请参阅CanIf_RxIndication（）），
它将执行以下比较，以选择在CanIfRxPduCfg中配置的正确接收L-SDU：
1.比较CanIfRxPduCanId与传递的Mailbox-> CanId
（Can_IdType）排除两个最高有效位
2.将CanIfRxPduCanIdType与传递的Mailbox-> CanId（Can_IdType）的两个最高有效位进行比较
在同一CAN网络上同时混合使用。 如果已使用配置参数CANIF_TXPDU_CANIDTYPE（参见ECUC_CanIf_00590）为BasicCAN或ExtendedCAN操作分别配置了BasicCAN / FullCAN硬件对象，则可以完成混合模式操作；对于混合模式操作，则可以使用软件接受过滤器算法（请参见第7.20节“软件”）。 接收过滤器”）必须能够处理两种类型的CanId。
EcuM调用CanIf函数CanIf_Init（）来初始化整个CanIf（请参阅[SWS_CANIF_00001]）。在初始化过程中，将初始化所有全局变量和数据结构，包括标志和缓冲区。 EcuM执行初始化
通过分别调用CanDrvs和CanTrcvs的相应初始化服务（请参阅[1]和[2，CAN收发器驱动程序规范]）。
CanIf期望CAN控制器保持在STOPPED模式，如初始化过程完成后的上电复位之后。在此模式下，CanIf和CanDrv无法发送或接收CAN L-PDU（请参阅[SWS_CANIF_00001]）。
如果需要在运行时重新初始化整个CAN模块，则EcuM必须调用CAN接口模块的API服务CanIf_SetControllerMode（）来调用CanSm（请参阅[3]）以启动所需的CAN控制器状态转换。
CanIf将来自CanSm的调用映射到相应的CanDrv的调用（请参见8.6.3
CanIf的传输请求函数CanIf_Transmit（）（[SWS_CANIF_00005]）是上层在CAN网络上传输L-PDU的通用接口。 上层
通讯层模块仅通过CanIf服务启动传输，而无需直接访问CanDrv。 如果CanDrv可以将L-PDU数据写入CAN硬件发送对象，则启动的发送请求成功完成。
上层模块使用API服务CanIf_Transmit（）发起传输请求（请参见第8.3.6节“ CanIf_Transmit”）。
CanIf在调用serviceCanIf_Transmit（）时对L-PDU传输执行以下操作：
1.检查，CanIf的初始化状态
2.识别CanDrv（仅当使用多个CanDrv时）
3.确定访问CAN硬件发送对象的HTH
4.调用CanDrv的Can_Write（）
如果传输请求服务CanIf_Transmit（）返回E_OK，则传输成功完成。 如果请求通过PDU发送L-PDU
通道模式（请参见第7.19.2节“ PDU通道模式”），等于CANIF_OFFLINE，CanIf应向DET的Det_ReportRuntimeError（）服务报告运行时错误代码CANIF_E_STOPPED，而CanIf_Transmit（）应返回E_NOT_OK。
2.1 传输数据流
2.2 传输缓冲
在CanIf的范围内，传输过程以对CanIf_Transmit（）的调用开始，并以上层模块的回调服务<User_TxConfirmation>（）的调用结束。
在发送过程中，CanIf，CanDrv和CAN Mailbox应当将要发送的L-PDU仅在一个位置存储一次。 根据传输方法，这些是：
1.CAN硬件发送对象或
2.如果启用了发送缓冲，则CanIf内的发送L-PDU缓冲区
对于触发的传输，CanIf仅必须存储给定L-PDU的传输请求，而不存储其数据。 当HTH空闲时（再次），将通过触发发送功能及时获取数据。 请求发送的单个Tx L-PDU，
不得存储两次。 此行为对应于CAN网络上常规通信的常规方式。
如果启用了发送缓冲，则如果CanDrv在发送请求时拒绝了Canx发送L-PDU缓冲区（CanIfBufferCfg），则CanIf会将Tx L-PDU存储在CanIf发送L-PDU缓冲区（CanIfBufferCfg）中。
基本上，CanIf中用于缓冲Tx L-PDU的整个缓冲区由一个或多个CanIfBufferCfg组成（请参见CanIfBufferCfg）。 每个CanIfBufferCfg分配给一个或多个专用的CanIfBufferHthRef（请参见CanIfBuffer-HthRef），并且可以配置为缓冲一个或多个Tx L-PDU。 但是，如上所述，每个Tx L-PDU只能缓冲一个CanIfBufferCfg总量。
在L-PDU传输期间CanIf的行为不同，是否在相应的Tx L-PDU的配置设置中启用了传输缓冲。如果禁用了传输缓冲，并且对CanDrv的传输请求失败（使用CAN控制器邮箱，BasicCAN），则L-PDU不会复制到CAN控制器的
邮箱和CanIf_Transmit（）返回值E_NOT_OK。如果启用了发送缓冲并且发送到CanDrv的请求失败，则取决于CanIfTxBuffer配置，L-PDU可以存储在CanIfTxBuffer中。在这种情况下，尽管无法执行传输，API CanIf_Transmit（）返回值E_OK。在这种情况下，CanIf负责L-PDU的出色传输
通过CanIf_TxConfirmation（）回调，上层无需重试传输请求。
可以完全独立于此ECU的CAN网络描述文件中定义的已使用发送L-PDU的数量来配置可用的发送CanIf Tx L-PDU缓冲区的数量。
根据[SWS_CANIF_00835]，Tx L-PDU通过CanIfBufferCfg配置容器（请参见CanIfBufferCfg）引用HTH。如果也不需要发送缓冲，则这是有效的。在这种情况下，必须将Can-IfBufferCfg的缓冲区大小（请参见CanIfBufferSize）设置为0。然后，CanIfBufferCfg配置容器仅用于引用HTH。
2.3 缓冲特性
CanIfTxPduBufferRef，CanIfBufferCfg，CanIfBufferHthRef和CanIf-
BufferSize描述可能的CanIfBufferCfg配置
2.3.1 L-PDU在发送L-PDU缓冲区中的存储
如果CanDrv在调用Can_Write（）的过程中返回CAN_BUSY（请参见[SWS_CANIF_00381]），则CanIf仅尝试在发送L-PDU缓冲区中存储新的发送L-PDU或其发送请求。
CanIf必须支持基本的CAN L-PDU的缓冲-
如果启用了CanIf（如果参数CanIfPublicTxBuffering）中的CAN传输
对于动态发送L-PDU，CanId也必须存储在CanIfTxBuffer中。
如果启用了传输缓冲（请参阅[SWS_CANIF_00063]）
如果配置为直接传输的PDU的Can_Write（）调用以CAN_BUSY返回，则CanIf将检查是否有可能在CanIfTxBuffer中缓冲请求通过Can_Write（）发送的CanIf Tx L-PDU。
当Can_Write（）的调用以CAN_BUSY返回时，CanDrv拒绝了请求的L-PDU传输（请参见[1]），因为在传输请求（Tx请求）时没有可用的可用硬件对象
如果拒绝的数据长度超过配置的大小，则CanIf
应：
1.缓冲配置的数据量并丢弃其余数据
2.并将运行时错误代码CANIF_E_DATA_LENGTH_MISMATCH报告给DET的Det_ReportRuntimeError（）服务。
如果启用了传输缓冲（请参阅[SWS_CANIF_00063]）
如果为触发传输配置的PDU的Can_Write（）调用返回CAN_BUSY，则CanIf将检查是否有可能在CanIfTxBuffer中缓冲请求通过Can_Write（）发送的传输请求。
2.3.2 清除发送L-PDU缓冲区
2.3.3 发送L-PDU缓冲区的数据完整性
CanIf应当防止同时访问发送L-PDU和发送请求的发送L-PDU缓冲区。
（SRS_Can_01114）这可以通过使用BSW Scheduler中定义的互斥区域来实现。
这些专属区域可以例如 配置为在进入独占区时将禁用所有中断。 来自BSW Scheduler模块的相应服务是SchM_Enter_CanIf（）和SchM_Exit_CanIf（）。
原理：对于[SWS_CANIF_00033]：始终不能避免对发送L-PDU缓冲区的抢占式访问。 这样的发送L-PDU缓冲区访问（例如存储新的L-PDU或删除发送的L-PDU）可能会抢先发生
2.3.4 发送确认
如果先前的发送请求成功完成，则CanDrv通过调用CanIf_TxConfirmation（）将其通知CanIf。
当回调通知时CanIf_TxConfirmation（）
调用时，CanIf将识别上层通信层
（请参阅[SWS_CANIF_00414]），该链接已成功传输的L-PDU，并应通过调用CanIf的传输确认服务<User_TxConfirmation>（E_OK）通知已执行的传输（请参阅第7.12节“传输
确认”）。
回调服务<User_TxConfirmation>（）由通知的上层模块实现。
可以以某种方式设计或配置上层通信层模块，可以使用针对不同L-PDU或L-PDU组的单个或多个回调服务来处理传输确认。 CanIf在对相应L-PDU传输请求的传输确认时调用所有这些服务。 发送L-PDU
使您能够分派与目标上层模块相关的不同确认服务。 该分配是在组态期间静态进行的。 一个发送L-PDU只能分配给一个发送确认回叫服务。 请参考第8.6.3.2小节“ <User_TxConfirmation>”。
2.4 接收数据流
根据AUTOSAR基本软件体系结构，将在上层通信堆栈（即AUTOSAR COM，CanNm，CanTp，DCM）中评估和处理接收到的数据。 这意味着上层模块可能无法使用（即
（更改）CanDrv（Rx）的缓冲区，也不能访问CanIf（Tx）的缓冲区。 CanIf仅在以下情况下在接收路径中提供内部缓冲：
CANIF_PUBLIC_READRXPDU_DATA_API（请参阅ECUC_CanIf_00607）设置为TRUE（请参阅第7.15节）。 Tx缓冲在第7.11节中介绍，动态L-PDU在第7.4节中介绍。
在新接收到L-PDU的情况下，CanDrv调用CanIf的CanIf_RxIndication（）（请参阅[SWS_CANIF_00006]）。 组织对L-PDU特定数据的访问
通过这些参数：
1.硬件接收句柄（HRH）
2.收到的CAN标识符（CanId）
3.接收数据长度
4.参考收到的L-PDU
接收到的L-PDU取决于硬件（半字节和字节顺序，访问类型），并分配给通信系统中的最低层-CanDrv。 HRH用作使用L-PDU的
CanDrv和上层模块之间的链接。 HRH标识一个CAN硬件接收对象，在该对象中接收到新的CAN L-PDU。
在CanDrv对接收到的L-PDU进行指示之后（调用CanIf_RxIndication（）），CanIf将按照7.14接收指示中所述进行。
CanIf无法识别CanDrv是使用临时缓冲还是直接硬件访问。 它期望在CanIf_RxIndication（）的调用中归一化的L-PDU数据。
接收到的L-PDU取决于硬件（半字节和字节顺序，访问类型），并分配给通信系统中的最低层-CanDrv。 HRH用作使用
L-PDU的CanDrv和上层模块之间的链接。 HRH标识一个CAN硬件接收对象，在该对象中接收到新的CAN L-PDU。
在CanDrv对接收到的L-PDU进行指示之后（调用CanIf_RxIndication（）），CanIf将按照7.14接收指示中所述进行。
CanIf无法识别CanDrv是使用临时缓冲还是直接硬件访问。 它期望在CanIf_RxIndication（）的调用中归一化的L-PDU数据。
CAN硬件接收对象被锁定，直到复制到临时或上层模块缓冲区的过程结束为止。 CanIf的CanIf_RxIndication（）返回后，将立即释放硬件对象，以避免数据丢失。
CanDrv，CanIf和属于接收的L-PDU的上层模块访问相同的临时中间缓冲区，该缓冲区可以位于CAN控制器的CAN硬件接收对象中，也可以作为CanDrv中的临时缓冲区
2.5 CAN Controller Mode
CanIf提供用于控制由底层CanDrv表示的所有受支持的CAN控制器的通信模式的服务。 这意味着所有CAN控制器都由相应提供的API服务控制，以请求和读取当前控制器模式。
通过调用CanIf_SetControllerMode（）服务，可以在上层请求时更改CAN控制器的状态。 CanIf通过CanDrv API将请求传递给寻址的CAN控制器。
对通过一个CAN网络连接的所有CAN控制器进行一致的管理是CanSm的任务。 这样，CanSm负责将一个CAN网络的所有CAN控制器顺序设置为睡眠模式或唤醒它们。
CanIf通过调用函数来接受每个状态转换请求
CanIf_SetControllerMode（）或CanIf_ControllerBusOff（）。 CanIf不能确定所请求的CAN控制器的模式转换是否有效。 CanIf仅通过获取当前模式并执行请求的模式转换来与CanDrv交互。
与网络相关的状态机在CanSm中实现。 请参阅[3]。 CanIf仅存储请求的模式并执行请求的转换。
提示：作为一种优化措施，以避免频繁向CanDrv请求内部
使用CanIf_ControllerModeIndication（）指示的最后一个状态，并
Can_GetControllerMode（）可以按控制器存储。
提示：必须考虑到，不仅CanSm能够请求更改CAN控制器模式。
2.5.1 CAN Controller Operation Modes
根据CanSm要求的操作模式，CanIf转发请求的CanDrv。
[SWS_CANIF_00677] d如果ControllerId引用的控制器模式处于CAN_CS_STOPPED状态，并且如果CanIf_Transmit（）调用中的PduIdType参数已分配给该CAN控制器，则CanIf_Transmit（）的调用不会导致Can_Write（ ）（请参阅[SWS_CANIF_00317]）并返回E_NOT_OK。
[SWS_CANIF_00485] d如果ControllerId引用的控制器模式进入状态CAN_CS_STOPPED，则CanIf将清除分配给相应的CAN Controller的CanIf发送缓冲区。 C（）
[SWS_CANIF_00739] d如果ControllerId引用的控制器模式进入状态CAN_CS_STOPPED，则CanIf应通过为分配给该CAN控制器的每个未完成的TxConfirmation调用<User_TxConfirmation>（id，E_NOT_OK）来通知相应的上层模块有关传输失败的信息。如果启用了CanIfPublicTxConfirmPollingSupport，则CanIf还应清除有关TxConfirmation的信息（参见[SWS_CANIF_00740]）。
注意：这确保了对于每个PDU，应通过
CanIf_Transmit（），将调用正或负<User_TxConfirmation>（）。
2.5.2 控制器模式转换
向CAN控制器发送状态更改请求的API会通过回调服务以异步方式进行异步通知。根据CAN控制器硬件中转换请求的设置，异步地发生真正的到请求模式的转换。要求睡眠转换CAN_CS_SLEEP。成功更改后，例如CAN_CS_SLEEP模式下CanDrv调用函数CanIf_ControllerModeIndication（）和CanIf
依次调用函数<User_ControllerModeIndication>（）。如果CAN转换非常快，则可以在CanIf_SetControllerMode（）期间调用CanIf_ControllerModeIndication（）。这是特定于实现的。
上层模块必须跟踪CAN控制器的不成功或没有模式转换。模式转换CAN_CS_STARTED和CAN_CS_STOPPED为
对待类似。
CanIf的上层模块可以通过以下方式轮询当前的控制器模式
CanIf_GetControllerMode（）。
并非所有类型的CAN控制器都支持睡眠和唤醒模式。然后，这些驱动程序由CanDrv封装，方法是通过其接口提供独立于硬件的操作模式，而该模式必须由CanIf管理。注意：在从CAN_CS_STOPPED到CAN_CS_SLEEP的过渡期间，可能
CAN控制器可能会向ECU集成代码指示唤醒中断。
CanIf区分内部启动的CAN控制器唤醒请求（内部请求）和网络唤醒请求（外部请求）。内部请求是通过调用CanIf函数CanIf_SetControllerMode（ControllerId，
CAN_CS_STARTED），这是一个内部异步请求。外部请求是CAN控制器事件，由CanDrv或CanTrcv通知给ECU集成
码。有关详细信息，请参见文档[13]的“ CAN唤醒序列”一章中的相应UML图。
2.5.3 唤醒
ECU仅在将CAN控制器和CAN收发器设置为某种“监听唤醒”模式的情况下，才支持通过CAN网络进行唤醒，而与所使用的唤醒方法无关（直接与CAN控制器或CAN收发器有关）。
这通常是一种睡眠模式，其中通常的通信被禁用。 只有此模式才能确保CAN控制器停止。 因此，可以使能唤醒中断。
2.5.4 唤醒检测
如果启用了唤醒支持（请参见[SWS_CANIF_00180]），则集成代码将CanIf通知服务CanIf_CheckWakeup（）检测到的CAN唤醒（请参见[13]的CAN唤醒序列）。
如果发生CAN总线“唤醒”事件，则可以在执行EcuM_CheckWakeup（WakeupSource）的过程中调用函数CanIf_CheckWakeup（WakeupSource）（请参阅EcuM的唤醒序列图）。 CanIf依次通过对CanDrvs中的EcuMWakeupSource的配置输入引用进行检查，必须检查哪个CanDrvs。 CanIf通过引用CanIfCtrlCanCtrlRef（请参阅ECUC_CanIf_00636）获取此信息。
被称为“通信服务”的通信服务属于配置期间定义的服务（请参阅ECUC_CanIf_00250）。 这样，EcuM和CanSm都可以更改CAN控制器状态并控制与BusOff恢复或唤醒过程有关的系统行为。
2.5.5 唤醒确认
注意：当CAN控制器/ CAN收发器检测到总线唤醒事件时，这将直接通知ECU状态管理器。 如果需要验证此类唤醒事件，则EcuM（或CDD）会打开相应的CAN控制器（CanIf_SetControllerMode（））和CAN收发器
注意：在将PDU通道模式设置为CANIF_ONLINE或CANIF_TX_OFFLINE之后，CanIf会将接收到的消息通知上层模块。
因此，如果需要唤醒验证，则必须不将PDU通道模式设置为CANIF_ONLINE或CANIF_TX_OFFLINE。 注意：根据[SWS_CAN_00411]和CAN控制器状态图（请参见[1]），不允许直接从模式CAN_CS_SLEEP转换为CAN_CS_STARTED。
2.6 PDU通道模式控制
2.6.1 PDU通道组
每个L-PDU分配给一个专用的物理CAN通道，该通道连接到一个CAN控制器和一个CAN网络。 通过这种方式，
可以从处理逻辑上单个L-PDU通道组的角度来控制属于一个物理通道的所有L-PDU。这些逻辑组代表连接到一个ECU的所有L-PDU
一个底层的CAN网络。
下面的图7.7显示了L-PDU信道组的一种可能用法及其与上层和/或网络的关系。
L-PDU只能分配给一个通道组。
诸如PduR或网络管理之类的典型用户负责控制PDU操作模式
2.6.2 PDU通道模式
CanIf提供服务CanIf_SetPduMode（）和CanIf_GetPduMode（）来
防止处理
1，所有发送属于一个逻辑信道的L-PDU
2.所有发送L-PDU和接收属于一个逻辑信道的L-PDU。
仅在相应控制器的情况下才允许更改PDU通道模式
模式等于CAN_CS_STARTED（请参阅[SWS_CANIF_00874]）。
当CANIF_ONLINE和CANIF_OFFLINE影响整个通讯时，
PDU通道模式CANIF_TX_OFFLINE和CANIF_TX_OFFLINE_ACTIVE启用/
分别禁用传输路径。
CanIf通过服务提供有关当前PDU通道模式的信息
CanIf_GetPduMode（）。
2.6.2.1 CANIF_OFFLINE
2.6.2.1 CANIF_ONLINE
2.6.2.1 CANIF_OFFLINE_ACTIVE
2.7 Software receive filter
并非所有可能通过硬件验收过滤器并因此在BasicCAN硬件对象中成功接收的L-PDU都被定义为接收L-PDU，因此需要从相应的ECU接收。 CanIf可以选择滤除这些LPDU，并禁止进一步的软件处理。
提供了某些软件过滤器算法来优化软件过滤器的运行时间。 软件过滤器机制的方法是从当前正在处理的HRH和CanId中找出相应的L-PDU。 找到L-PDU后，CanIf接受接收并允许上层直接访问L-SDU信息。
2.7.1 软件过滤的概念
配置工具处理有关硬件验收筛选器设置的信息。
最重要的设置是L-PDU硬件对象的数量及其范围。 出口范围定义了哪些接收L-PDU属于每个硬件接收对象。 以下定义是可能的：
1.单个接收L-PDU（FullCAN接收），
2.接收L-PDU列表或
3.可以将一个或多个接收L-PDU范围链接到硬件接收
对象（BasicCAN接收）。
每个CanId的可配置范围
（请参阅[SWS_CANIF_00645]），该软件应通过软件接收过滤器，并且可以通过以下方式配置为标准CAN ID或扩展CAN ID：
CANIF_HRHRANGE_CANIDTYPE（请参阅ECUC_CanIf_00644）。 C（）
提供接收L-PDU作为从通信矩阵静态生成的恒定结构。它们根据相应的硬件接受筛选器进行排列，因此每个硬件只有一个接收CanId的列表
接收对象（HRH）。如果使用了多个BasicCAN对象，则对应的列表可以由HRH派生。随后的过滤是通过将多个CanId与新接收的CanId进行比较来搜索一个列表。在命中的情况下，接收的L-PDU从找到的CanId派生。
[SWS_CANIF_00030] d如果已配置为接收HRH中接收到的L-PDU的CanId，则CanIf将接受该L-PDU，并且软件过滤算法将从发现的CanId中得出相应的接收L-PDU。
2.7.2 Data Length Check
将接收到的数据长度值与接收到的L-PDU的已配置数据长度值进行比较。 配置的数据长度值应从该L-PDU内部使用的字节大小中得出。 所配置的数据长度值可能不一定是在CAN通信矩阵中定义并由该CAN L-PDU的发送方使用的数据长度值。
CanIf将接受所有收到的L-PDU
（请参见[SWS_CANIF_00390]），并且数据长度值等于或大于配置的数据长度值
如果数据长度检查拒绝收到的LPDU
（请参见[SWS_CANIF_00026]），CanIf将报告运行时错误代码
CANIF_E_INVALID_DATA_LENGTH到Det_ReportRuntimeError（）服务
DET模块的名称。