一、簡介
該規范描述了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節中詳細說明。
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模塊的名稱。