電子發燒友App
1.IpduM功能簡介
IpduM模塊在AUTOSAR分層架構中位于PduR模塊的旁邊。
PDU多路復用意味著使用PDU（協議數據單元）的相同PCI（協議控制信息），其SDU（服務數據單元）的多個唯一布局。選擇器字段是多路PDU的SDU的一部分。它用于區分多路PDU之間的內容。
PDU的多路復用是目前已知的來自CAN的方法，但并不局限于此通信系統。
在發送方端，I-PDU多路復用器模塊負責將適當的I-PDU從COM組合到新的、多路復用的I-PDU，并將它們發送回PduR模塊。在接收端，它負責解釋多路I-PDU的內容，并考慮到選擇器字段的值，為COM提供適當的分離I-PDU。
2.IpduM模塊依賴的其他模塊
2.1RTE (BSW Scheduler)
IpduM模塊依賴于BSW調度器，分別在IpduMRxTimeBase或IpduMTxTimeBase中配置的時間點調用IpduM_MainFunctionRx和IpduM_MainFunctionTx。
2.2PDU Router
以下總?結了IpduM所需要的來自PDU路由器的功能：
1）指示接收到了包含多路復用的I-PDU
2）輸出i-pdu的發送接口
3）發送報文確認
以下列表總結了IpduM模塊為PduR模塊提供的功能：
1）可進行多路復用的輸入I-PDU和待拆卸的輸入容器-pdu的指示接口
2）為一個多路復用的i-pdu提供發送接口，它們將被組裝成一個容器PDU
3）已傳輸的I-PDU的確認接口
PduR模塊的配置必須使能夠表示多路I-PDU的I-PDU路由到IpduM模塊的靜態或動態部分：
1）I-PDU，它屬于多路復用的I-PDU，表示一個多路復用的I-PDU的靜態或動態部分
2）I-PDU，它由要進行多路復用的靜態和動態部分組成
3）I-PDU，它將被組裝成一個容器PDU
4）提供容器來存放要被拆分的多路復用I-PDU
2.3COM
IpduM模塊的配置依賴于COM模塊的相應配置。對于每個多路復用的I-PDU，靜態部分和動態部分的每個布局都需要有不同的I-PDU。
IpduM進一步假定正確的選擇器字段值已經包含在表示動態部分的COM的模塊I-PDU中。
3.IpduM功能詳解
3.1?功能概述
有兩種不同的方法可以將多個I-PDU多路復用到一個在總線上傳輸的結果PDU中：
1）I-PDU Multiplexing。I-PDU多路復用意味著使用從PduR傳輸到通信硬件抽象層的相同的I-PDU ID，并具有該I-PDU的多個唯一布局。
2）Multiple PDU to Container Mapping。多個PDU到容器的映射意味著將多個i-PDU收集到一個容器PDU中。然后，這個容器PDU通過PduR作為一個（大的）I-PDU傳輸。這種方式可以利用新總線系統的優勢，允許與更小的I-PDU大?。ㄍǔＪ?字節）一起有效地使用帶寬。
3.2?I-PDU多路復用I-PDU Multiplexing
3.2.1 Definitions and Layout
一個多路復用的I-PDU由一個靜態部分和一個動態部分組成，其中靜態部分由零個或多個信號或信號組組成。動態部分由選擇器字段和一個或多個信號或信號組組成，請參見圖3。I-PDU的動態部分可與C語言的union相比較。根據I-PDU內的選擇器字段的值，將選擇I-PDU的實際布局。
靜態部件和動態部件的位置可根據I-PDU進行配置。靜態部分和動態部分可以被細分為不同的部分。對于每個多路復用的I-PDU，只能定義一個選擇器字段。選擇器字段的值定義了如何解釋I-PDU的動態部分的內容。選擇器字段具有在1到16個連續位之間的可配置大小，其位置可以通過配置來定義。
pdu的多路復用最初來自于CAN，但它并不局限于這個通信系統。在AUTOSAR體系結構中，位于接口層（通信硬件抽象）上方的PDU路由器分層，因此該特性可以用于所有總線系統，可以由PDU路由器處理，例如FlexRay。
3.2.2通用功能描述 General
靜態部分有一個COM I-PDU，一個復用IpduM I-PDU的動態部分的每個布局有一個COM I-PDU，因此IpduM最多組合兩個COM的I-PDU。
IpduM模塊不應設置選擇器字段。選擇器字段的字節序通過IpduMByteOrder參數配置。
IpduM模塊依賴于COM模塊的配置。對于每個動態布局，都需要在COM中配置一個I-PDU。這樣的i-pdu已經必須包含正確的選擇器字段值。COM中的選擇器字段值可以通過配置為信號來初始化，這些信號用init值初始化，但在初始化后不會寫入。
應允許優化從IpduM模塊到PDU路由器模塊的Rx-和Tx-確認路徑，直接從IpduM模塊調用COM API，而不包括PduR模塊。這個功能通過配置IpduMRxDirectComInvocation參數可以實現。
3.2.3模塊初始化 Initialization
IpduM_Init函數完成IpduM模塊的初始化。
對于通過IpduM模塊的I-PDU數據傳輸路徑，在IpduM模塊內分配了一個緩沖區。這個緩沖區需要初始化，因為它可能在COM模塊完全填充數據之前傳輸。此緩沖區的初始化數據來自COM模塊配置的初始值，如下：
1）IpduM應使用配置的模式IpduMIPduUnusedAreasDefault.初始化其內部傳輸緩沖區。
2）動態部分的信號的初始值應參考 COM I-PDU (IpduMInitialDynamicPart -> IpduMTxDynamicPart -> IpduMTxDynamicPduRef所應用的PDU的初始值。
3）靜態部分的信號的初始值應參考 COM I-PDU (IpduMTxStaticPart -> IpduMTxStaticPduRef所應用的PDU的初始值。
選擇器字段包含在初始動態部分的一個段中，因此被隱式地初始化。
為了進行優化，緩沖區可以在配置時計算出初始位模式，然后在運行時進行復制。
3.2.4 數據傳輸Transmission
在COM內部，靜態部分有獨立的I-PDU，多路I-PDU的每個動態部分都有一個。
靜態部分和動態部分在COM中被視為單獨的I-PDU，并且它們有自己的i-pduid。
對于多路I-PDU，IpduM應將對應的兩個代表相關靜態部分和最后接收到的動態部分的COMI-PDU合并為一個I-PDU，具有一個新的唯一I-PDU ID。IpduM將將這個新的IpduM I-PDU發送到PduR模塊。
所有的控制功能，如COMI-pdu的deadline monitoring和 update-bit評估，必須由COM層來完成。
Transmission request
IpduM模塊提供了一個IpduM_Transmit功能，使PDU路由器能夠啟動I-PDU的傳輸。
功能IpduM_Transmit應使用相關的靜態和動態部分組裝多路復用的I-PDU。
每個輸出的I-PDU都有一個初始值，因此，在靜態和動態部件從COM發送到IpduM之前，IpduM模塊傳輸I-PDU，則傳輸由配置定義的值。
只要沒有接收到IpduM I-PDU的傳輸確認（無論結果如何），函數IpduM_Transmit將返回E_NOT_OK。
如果多路I-PDU僅通過更新動態或靜態部分來觸發發送，那么如果在兩次傳輸之間進行多次更新，非觸發部分可能會被覆蓋。
Transmission trigger
IpduM模塊通過兩個來自PduR模塊的兩個傳輸請求來接收多路I-PDU的靜態和動態部分。
IpduM模塊應可配置為向PduR發送針對新的多路I-PDU的傳輸請求：
1）接收到I-PDU的靜態部分信號
2）接收到I-PDU的動態部分信號
3）接收到I-PDU的靜態或者動態部分信號
4）在觸發傳輸時，由于接收到任何此I-PDU（IpduMTxTriggerMode None）而不觸發傳輸。
四種觸發條件/模式允許通過COM發送的單個I-PDU的傳輸模式來控制新組裝的I-PDU的傳輸模式。
并不是所有的四種觸發條件/模式都保證了多路復用i - pdu不同實例之間連續傳輸的最小延遲時間，因為如果傳輸是由靜態和動態部分觸發的，或者僅由動態部分觸發，COM不會考慮最小延遲時間。COM將靜態部分和不同的動態部分視為不相關的獨立i - pdu。
如果I-PDU只因為下層的觸發傳輸而被發送出去，則需要配置“因為接收到任何東西而不觸發傳輸”。使用API IpduM_TriggerTransmit，較低的層可以觸發I-PDU的發送。
當IpduMTxTriggerMode為None時，下級通過IpduM_TriggerTransmit觸發傳輸協議時，IpduMTxConfirmationPduId需要配置，因為IpduM_TriggerTransmit時，IpduMTxConfirmationPduId也用于解析I-PDU。
Just-In-Time update of parts
有時，IpduM模塊可能不只是發送本地存儲的部分，因為這些部分可能包含過時的信息，例如更新位。因此，IpduM支持每個部分都有一個可配置的即時更新機制。
如果一個部分的更新觸發了多路I-PDU的傳輸，而第二個部分的IpduMJitUpdate配置為true，則IpduM模塊必須先通過PduR_IpduMTriggerTransmit更新第二個部分，然后再通過PduR_IpduMTransmit發送多路I-PDU。
如果通過IpduM_TriggerTransmit請求一個多路復用I-PDU的內容，IpduM模塊在返回多路復用I-PDU的內容之前，必須更新所有配置了IpduMJitUpdate的部分。
如果IpduM需要及時更新動態部分，則更新上層發送的最新動態部分，如果之前沒有發送動態部分，則更新IpduMInitialDynamicPart引用的動態部分。
如果一個多路I-PDU的更新觸發了一個多路I-PDU的傳輸，而第二個部分的IpduMJitUpdate配置為true，那么如果通過PduR_IpduMTriggerTransmit的jit更新請求返回E_NOT_OK，則該多路I-PDU將不發送。
如果通過IpduM_TriggerTransmit請求多路I-PDU的內容，并且IpduMJitUpdate為任何多路部分配置為true，如果通過PduR_IpduMTriggerTransmit的任何JIT-update re請求返回E_NOT_OK, IpduM_TriggerTransmit將返回E_NOT_OK。
Transmission confirmation
根據PDU Router中i -PDU的配置，PDU Router ac向IpduM模塊發送傳輸確認。
如果IpduM接收到一個特定IpduM I-PDU的TxConfirmation，它應該將這個確認轉換為COM I-PDU的相應確認，這些確認包含在最后發出的多路復用IpduM I-PDU中。
根據IpduMTxDynamicConfirmation和IpduMTxStaticConfirmation的配置，對于一個發送請求，IpduM將向COM傳遞零、一個或兩個確認。給上層的確認次數不依賴于IpduMTxTriggerMode。
Examples:
1）如果對應的IpduMTxRequest的IpduMTxDynamicConfirmation和IpduMTxStaticConfirmation都不配置為true，則不生成COM確認。
2）如果IpduMTxStaticConfirmation配置為true，而IpduMTxDynamic確認配置為false(反之亦然)，則只生成一個COM確認。
3）如果IpduMTxStaticConfirmation和IpduMTxDynamicConfirmation都配置為true，則會生成兩個COM確認;到表示所述靜態部分的I-PDU和表示所述動態部分的I-PDU。
如果生成了兩個傳輸確認，它們顯然是相等的，因為它們來自同一個I-PDUM傳輸確認。
3.2.5 數據接收Reception
通信硬件抽象(CAN接口、Lin接口、FlexRay接口)接收到的每個I-PDU都被發送給PDU路由器。PDU Router將多路i -PDU路由到IpduM模塊。IpduM模塊將多路復用I-PDU的靜態部分和動態部分分開路由到它們的目的地。
在配置時，已知傳入的I-PDU id對應于配置了靜態部分的多路復用I-PDU。I-PDU ID是判斷是否存在靜態部件所需的全部信息。
由于所有多路復用i - pdu都包含一個動態部分，因此該部分總是必須被路由。
沒有處理或通知錯誤配置的部件的要求。因此，如果接收到的I-PDU包含未在ECU上配置為接收的段，它們將被無聲地忽略。此外，如果一個I-PDU配置了PduLength為0，它也將被無聲地忽略，因為沒有任何有意義的處理可以配置。
這種情況可能發生在網關設置中，如果一個多路復用I-PDU總是被PDU路由器路由到另一個總線上，但在一個動態部分中包含一個必須傳遞給應用程序的信號。在這種情況下，多路復用PDU也必須路由到IpduM。
3.2.6 元數據處理Metadata handling
僅當“IpduMMetaDataSupport”配置為“true”時，本節要求才適用。
如果IpduMTxTriggerMode配置為與NONE不同的值，IpduM將使用觸發部分的MetaData發送多路I-PDU。
如果配置了“IpduMTxTriggerMode”為“NONE”，則IpduM發送多路I-PDU時，將使用上次更新部分的元數據。
在接收端，IpduM應將接收到的元數據連同所有解復用部分一起轉發。
3.3Multiple-PDU-to-Container handling
IpduM支持將多個i -PDU映射到一個Container PDU。從PduR的角度來看，包含式pdu和容器式pdu都是普通的pdu。容器布局既可以在包含的i - pdu前使用標頭動態定義，也可以不使用標頭靜態定義，但為包含的i - pdu定義靜態位置。
IpduM依賴于PduR被配置為將映射到Container-PDU的發送pdu轉發給IpduM，并將接收到的container pdu轉發給IpduM。
3.3.1 Dynamic Container Layout
在動態容器PDU中，IpduM應將包含的I-PDU的頭置于包含的I-PDU的前面。
對于動態容器PDU，容器PDU中所包含的I-PDU的位置沒有配置，因此任意一個包含I-PDU的位置是由負載(DLC)的長度和前面(之前添加的)包含I-PDU的頭來決定的。
容器PDU中i -PDU的數量受容器PDU最大大小的限制。
容器PDU中i -PDU的順序將被保留。通過這種方式，所有受保護的i -PDU都按照它們被放入con tainer PDU中的相同順序被提取。
IpduM支持動態容器pdu的兩種不同的報頭大?。?IpduMContainerHeaderSize）：
. IPDUM_HEADERTYPE_SHORT with 24 bit ID and 8 bit length
. IPDUM_HEADERTYPE_LONG with 32 bit ID and 32 bit length
頭大小通過IpduMContainerHeaderSize配置每個Container PDU。因此，它對整個容器PDU都有效。不支持在一個Con?tainer PDU內混合頭部大小。
每個I-PDU報頭由ID字段和length字段組成，字節順序由IpduMHeaderByteOrder決定。
動態容器PDU中所含i -PDU的頭和有效載荷的放置應該是連續的，沒有任何間隙。
原理:這允許通過考慮報頭大小和有效載荷長度(來自報頭的DLC)在容器PDU上迭代。
這必須通過容器收集算法的實現來確保，因為包含的i -PDU在容器PDU中沒有專用的(配置的)位置。
3.3.2Static Container Layout
當將包含的I-PDU添加到尚未觸發的容器PDU中時，如果將IpduMContainedTxPduTrigger設置為IPDUM_TRIGGER_ALWAYS，則容器PDU立即被觸發。
當IpduMContainerTxFirstContainedPduTrigger參數設置為TRUE時，IpduM將第一個包含的I-PDU添加到容器PDU中，需要調用PduR_IpduMTransmit。
原理:通過這種方式，對時間觸發總線請求傳輸。
3.3.3 Transmission
當將第一個包含的I-PDU添加到容器PDU中，且容器PDU的IpduMContainerTxSendTimeout或包含的I-PDU的IpduMCon (IpduMCon) tainedTxPduSendTimeout配置為大于零時，IpduM模塊將啟動容器PDU的傳輸定時器。定時器初始化為IpduMContainerTxSendTimeout和IpduMContainedTxPduSendTimeout中較小的非零值。
直到容器PDU被取走，或者除非容器PDU的最大大小沒有超過，否則可以添加分配給該容器的請求i -PDU。
當一個包含的I-PDU被添加到容器PDU中時，如果包含的I-PDU的超時時間小于容器PDU的剩余時間，則容器PDU的傳輸計時器將被更新為包含的I-PDU的超時時間(IpduMContainedTxPduSendTimeout)。
當容器PDU的傳輸定時器結束時，容器PDU將被觸發。
當Container PDU被觸發時，IpduM將調用PduR_IpduMTransmit。
將容器PDU傳遞給PduR時，參數 (PduInfoPtr)應包含一個指向已組裝的容器PDU (SduDataPtr)的指針，并包含SduLength (SduLength)的總長度。
Queueing
如果一個容器PDU的多個實例必須由IpduM保存，除了當前的數據之外，最多可以存儲IpduMContainerQueueSize實例。當前實例是當前包含i -PDU的容器PDU的一個實例。在該實例被排隊或復制到下層之后，即在根據IpduMContainerTxTriggerMode的配置調用TriggerTransmit或Transmit API之后，不能再將包含的i - pdu添加到該實例中。
如果PduR_IpduMTransmit已經返回E_NOT_OK，在下一次調用IpduM_MainFunctionTx時，將重復相同的傳輸請求。與此同時，該Container PDU的實例處于排隊狀態。
在為該容器PDU的下一個實例調用PduR_IpduMTransmit之前，IpduM應等待傳輸確認(無論結果如何)。
IpduM模塊在這里依賴于為下層的Container PDU配置的傳輸確認。
如果收到該容器PDU的傳輸確認，IpduM將在下次調用IpduM_MainFunctionTx時最遲為該容器PDU的下一個舊實例調用PduR_IpduMTransmit。
如果IpduMContainerTxTriggerMode被設置為IPDUM_DIRECT，并且PduR_IpduMTransmit為該容器PDU返回E_OK, IpduM將從隊列中刪除該實例。
在這種情況下，如果使用CanIf中的隊列，Container-PDU的實例可能會丟失，因為較新的實例可能會覆蓋之前的實例。這種最后是最好的行為在這種情況下可能不可取。
如果IpduM接收到一個特定的包含PDU的TxConfirmation，它應該將此確認轉換為那些包含IpduMContainedTxPduConfirmation設置為TRUE的I-PDU的相應確認，并且包含在容器I-PDU的最后一個發送實例中。如果包含的相同I-PDU出現多次，則會導致多個txconfirmation。
如果創建一個Container PDU的新實例超過了IpduMContainerQueueSize，那么舊的實例將被丟棄。如果沒有配置IpduMContain erQueueSize，則丟棄本地實例。在這兩種情況下，IPDUM_E_QUEUEOVFL將通過Det_ReportRuntimeError報告給DET。
如果一個容器PDU實例被TriggerTransmit讀取，它將從隊列中刪除。
Triggered Transmission and Last-is-Best semantics
如果IpduMContainerTxTriggerMode設置為IpduM_TriggerTransmit, IpduM將保留并提供緩沖數據，直到調用IpduM_TriggerTransmit來獲取數據。
如果IpduMContainerTxTriggerMode設置為IpduM_TriggerTransmit，則IpduM_TriggerTransmit將復制隊列中最古老的container PDU實例。如果隊列為空或不存在，則復制Container PDU的當前實例。如果容器PDU的當前實例為空/不存在(不存在)，則由IpduM_TriggerTransmit返回E_NOT_OK。
對于被包含的I-PDU，如果ipdumcontainedtxducollec tionSemantics設置為IPDUM_COLLECT_LAST_IS_BEST, IpduM在將容器I-PDU傳輸到下層之前，將使用PduR_IpduMTriggerTransmit從上層獲取PDU數據。
雖然將ipdumcontainedtxducollectionsemantics IPDUM_COLLECT_LAST_IS_BEST與IpduMContainerTxTrigger Mode IPDUM_TRIGGERTRANSMIT結合使用似乎很自然，但它也可以與IPDUM_DIRECT結合使用。
一旦一個包含的I-PDU被配置為使用最后是最好的語義，用戶就會接受這個包含的I-PDU的所有實例/值不一定在網絡上都是可見的。另一方面，隊列收集語義保證所包含I-PDU的每個實例/值在線路上都是可見的。
3.3.4Transmission of Dynamic Containers
由于以下要求，IpduM將確保一個包含的I-PDU(相同的PDU-ID)的實例以與它們傳遞給IpduM的順序完全相同的順序傳輸(傳遞給容器pdu中的PduR)。
當一個ipdumcontainedtxducolletionsemantics設置為IPDUM_COLLECT_QUEUED的I-PDU通過IpduM_Transmit傳遞給IpduM時，IpduM將識別相關的容器PDU并將包含的I-PDU附加到其有效負載，即使容器PDU中已經存在包含的I-PDU的先前實例。
通過這種方式，一個Container PDU可以包含同一個I-PDU的多個實例。產生的行為類似fifo，以保持正在傳輸的I-PDU實例的順序。因此，接收IpduM的上層可以實現最后是最好的語義或FIFO（ last-is-best or FIFO）語義。
如果一個包含的I-PDU已經被添加到尚未觸發的容器PDU中，并且如果產生的有效載荷大于IpduMContain erTxSizeThreshold，則容器PDU將被觸發。
如果IpduMContainerTxTriggerMode設置為IPDUM_DIRECT，添加一個包含的I-PDU將超過容器I-PDU的最大大小，則首先觸發容器PDU。所包含的I-PDU應添加到Container PDU的新實例中。
如果IpduMContainerTxTriggerMode設置為IPDUM_TRIGGERTRANSMIT，添加包含的I-PDU將超過容器PDU的最大大小，則首先將容器PDU排隊。然后將包含的I-PDU添加到Container PDU的新實例中。
包含的i - pdu將使用IpduMContainerTxTrigger Mode = IPDUM_TRIGGERTRANSMIT添加到容器pdu，只要它們既沒有滿也沒有排隊。
當一個Container PDU被TriggerTransmit觸發或提取后，IpduM將計算Container PDU的整體大小。總大小由包含的i - pdu的所有有效負載之和加上相應報頭的總長度構成。其結果應為容器PDU的有效載荷大小。
Triggered Transmission and Last-is-Best semantics
如果包含ipdumcontainedtxducollectionsemantics設置為IPDUM_COLLECT_LAST_IS_BEST的i - pdu, IpduM模塊會在發送前更新這些i - pdu。如果這些包含的i - pdu具有動態大小，則可能發生容器大小不足以容納所有包含的i - pdu，如果已過期的i - pdu的總體大小增加。
如果使用IpduMCon tainedtxducollectionsemantics IPDUM_COLLECT_LAST_IS_BEST更新包含的I-PDU，并且container的大小不足以容納一個包含的I-PDU，那么這個包含的I-PDU和所有后續的I-PDU將被轉移到下一個容器實例的開頭。
為了保持包含的i - pdu的順序，即使當前容器中有足夠的空間，也需要轉移所有后續包含的i - pdu。
當將包含的i - pdu存儲到容器pdu中時，IpduM應保留包含的i - pdu傳遞給IpduM的順序。也就是說，第一個傳遞的包含I-PDU被放置在容器的開頭，以此類推。如果一個包含ipdumcontainedtxducollectionsemantics設置為IPDUM_COLLECT_LAST_IS_BEST的I-PDU被多次傳遞，IpduM將只在它第一次出現的位置存儲它一次。
如果PduR_IpduMTriggerTransmit為包含的I-PDU返回E_NOT_OK, IpduM將隱去包含的I-PDU。相關的容器PDU無論如何都將傳輸，而不包含省略的I-PDU。在跳過的I-PDU后面的所有包含I-PDU都將按照包含省略的I-PDU(包括其頭部)的大小向上移動。
3.3.5 Transmission of Static Containers
對于靜態容器布局的Container PDU，如果IpduMContainerTxTriggerMode設置為IPDUM_DIRECT，則當所有包含的i -PDU被上層更新時，IpduM將觸發Container PDU。
由于靜態容器可能包含未更新的包含i - pdu，因此在接收端有方法檢測包含i - pdu的當前狀態。為包含的i - pdu或unsed區域的默認模式配置更新位。
如果所包含的I-PDU配置了Ipdu (PDU)的MUpdateBitPosition，當且僅當所包含的I-PDU被成功更新時，IpduM應確保該I (PDU)的更新位被設置。
如果靜態容器配置了IpduM(節點)的UnusedAreasDefault，則IpduM應確保在容器PDU發送之前，容器(節點)的所有未更新區域都被設置為IpduMUnusedAreasDefault值。
這允許IpduM處理靜態容器中包含的具有動態長度的i - pdu。但是，如果SWC或發送ip設置了IpduMUnusedAreasDefault-value，則接收ip無法檢測到。因此，總是會接收到完整的，最終被填充的包含I-PDU。
必須注意到，一些總線(如CAN-FD和FlexRay)不能傳輸任意長度的pdu，可能會用自己的默認值將發送的I-PDU填充到下一個可能的長度。因此，IpduM的UnusedAreasDefault值的配置應該與總線特定的填充模式保持一致。
3.3.6 Reception
如果“IpduMContainerPduProcessing”設置為“ IPDUM_PROCES_SING_IMMEDIATE”，則對接收到的容器pdu進行“IpduM_RxIndication”的處理。否則，它將被延遲到下一次對IpduM_MainFunctionRx的調用。所有延期的集裝箱pdu應按照接收順序進行處理。
如果通過調用IpduM_RxIndication，容器PDU被重新接收，包含的i -PDU將被提取。
如果容器PDU的IpduMContainerRxAcceptCon tainedPdu設置為IPDUM_ACCEPT_CONFIGURED, IpduM將只期望并匹配IpduMContainedRxIn ContainerPduRef中引用容器PDU的包含的i -PDU。
每個包含的I-PDU通過PduR_IpduMRxIndication通知PduR。IpduM應按照容器PDU中i -PDU的位置順序指示所包含的i -PDU。
Queueing
如果收到Container PDU，且“IpduMContainerPduPro PDU處理”設置為“IPDUM_PROCESSING_DEFERRED”，則該Container PDU將進入隊列。
如果接收到的容器PDU的新實例超過了IpduMContainerQueueSize，則舊實例將被丟棄，并通過Det_ReportRuntimeError將IPDUM_E_QUEUEOVFL報告給DET。
3.3.7 Reception of Dynamic Containers
對于每個包含的I-PDU，其頭部應使用的ID用于標識對應的I-PDU:
. 如果接收到的容器使用長頭(IpduMContainerHeaderSize = IPDUM_HEADERTYPE_LONG)，則該ID將與IpduMCon (IpduMCon)的長頭(IpduMCon)進行比較。
. 如果接收到的容器使用短頭(IpduMContainerHeaderSize = IPDUM_HEADERTYPE_SHORT)，則該ID將與IpduMContainedRxPduShortHeaderId進行比較。
如果對于容器PDU, IpduMContainerRxAcceptCon tainedPdu設置為IPDUM_ACCEPT_ALL, IpduM將期望并匹配所有受控的i -PDU，而不依賴于IpduMContainedRxInContainerPduRef。
如果提取的包含I-PDU不能根據其ID匹配，它將被默默地丟棄。
對于每個包含的I-PDU，其頭應使用中給出的長度為對應的I-PDU的長度。
當處理接收到的容器PDU并檢測到包含ID 0的報頭時，對該容器PDU的處理應停止，其余字節應被忽略。
原理:頭ID為0意味著容器PDU已被填充字節填充，不再包含進一步的數據。
3.3.8 Reception of Static Containers
為了讓接收IpduM模塊能夠確定接收到的靜態容器中的哪些PDU已經在發送端被更新，可以為每個包含的I-PDU配置額外的更新信息，即容器PDU中的PDU更新位。
對于接收到的包含I-PDU，如果配置了更新位，則IpduM模塊只對其進行處理，并將其指示給上層。
上述需求會導致靜默地忽略已配置但未設置更新位的包含i - pdu。
未配置更新位的i - pdu始終被處理并指示給上層。假設它們總是有效的。
3.3.9 Errorhandling
有些總線系統不可能為傳輸的L-PDU設置任意大小(例如canfd)。容器PDU的有效負載長度可以從包含的報頭中得到。因此，與Container PDU實際長度的差值可視為填充。
假設底層總線模塊的配置使填充值不構建有效的報頭。
當處理接收到的容器PDU并檢測到有效載荷長度超過容器剩余字節的報頭時，對該容器PDU的處理應停止并忽略剩余字節。另外，IPDUM_E_HEADER需要通過Det_ReportRuntimeError上報給DET。
有效負載長度大于剩余字節的標頭（header）無效。在它后面不會再有頭（header）了。
如果Container PDU中剩余的字節小于配置的IpduMContainerHeaderSize，剩余的字節將被忽略。
當處理一個IpduMContainerHeaderSize設置為IPDUM_HEADERTYPE_NONE的容器PDU時，IpduM將忽略所有根據其配置不包含或不完全包含在接收到的容器PDU中的PDU。這些包含的i - pdu不能顯示給上層。如果配置了開發錯誤檢測，IPDUM_E_CONTAINER將通過Det_ReportError報告給DET。
3.3.10 Metadata handling
如果Container PDU支持元數據，則IpduM在發送Container PDU時應使用從包含的i -PDU中最后收集的元數據。
如果IpduM接收到帶有元數據的容器PDU，則IpduM應將容器PDU的元數據連同所有包含支持元數據的I-PDU一起轉發。
IpduM不重新排列元數據。因此，它只支持分配給相同容器pdu的包含i - pdu，這些容器pdu沒有元數據或具有相同的元數據類型。
編輯：黃飛
?
工商網監
評論