1.IpduM功能簡介

IpduM模塊在AUTOSAR分層架構(gòu)中位于PduR模塊的旁邊。

PDU多路復(fù)用意味著使用PDU（協(xié)議數(shù)據(jù)單元）的相同PCI（協(xié)議控制信息），其SDU（服務(wù)數(shù)據(jù)單元）的多個唯一布局。選擇器字段是多路PDU的SDU的一部分。它用于區(qū)分多路PDU之間的內(nèi)容。

PDU的多路復(fù)用是目前已知的來自CAN的方法，但并不局限于此通信系統(tǒng)。

在發(fā)送方端，I-PDU多路復(fù)用器模塊負責(zé)將適當(dāng)?shù)腎-PDU從COM組合到新的、多路復(fù)用的I-PDU，并將它們發(fā)送回PduR模塊。在接收端，它負責(zé)解釋多路I-PDU的內(nèi)容，并考慮到選擇器字段的值，為COM提供適當(dāng)?shù)姆蛛xI-PDU。

2.IpduM模塊依賴的其他模塊

2.1RTE (BSW Scheduler)

IpduM模塊依賴于BSW調(diào)度器，分別在IpduMRxTimeBase或IpduMTxTimeBase中配置的時間點調(diào)用IpduM_MainFunctionRx和IpduM_MainFunctionTx。

2.2PDU Router

以下總?結(jié)了IpduM所需要的來自PDU路由器的功能：

1）指示接收到了包含多路復(fù)用的I-PDU

2）輸出i-pdu的發(fā)送接口

3）發(fā)送報文確認

以下列表總結(jié)了IpduM模塊為PduR模塊提供的功能：

1）可進行多路復(fù)用的輸入I-PDU和待拆卸的輸入容器-pdu的指示接口

2）為一個多路復(fù)用的i-pdu提供發(fā)送接口，它們將被組裝成一個容器PDU

3）已傳輸?shù)腎-PDU的確認接口

PduR模塊的配置必須使能夠表示多路I-PDU的I-PDU路由到IpduM模塊的靜態(tài)或動態(tài)部分：

1）I-PDU，它屬于多路復(fù)用的I-PDU，表示一個多路復(fù)用的I-PDU的靜態(tài)或動態(tài)部分

2）I-PDU，它由要進行多路復(fù)用的靜態(tài)和動態(tài)部分組成

3）I-PDU，它將被組裝成一個容器PDU

4）提供容器來存放要被拆分的多路復(fù)用I-PDU

2.3COM

IpduM模塊的配置依賴于COM模塊的相應(yīng)配置。對于每個多路復(fù)用的I-PDU，靜態(tài)部分和動態(tài)部分的每個布局都需要有不同的I-PDU。

IpduM進一步假定正確的選擇器字段值已經(jīng)包含在表示動態(tài)部分的COM的模塊I-PDU中。

3.IpduM功能詳解

3.1?功能概述

有兩種不同的方法可以將多個I-PDU多路復(fù)用到一個在總線上傳輸?shù)慕Y(jié)果PDU中：

1）I-PDU Multiplexing。I-PDU多路復(fù)用意味著使用從PduR傳輸?shù)酵ㄐ庞布橄髮拥南嗤腎-PDU ID，并具有該I-PDU的多個唯一布局。

2）Multiple PDU to Container Mapping。多個PDU到容器的映射意味著將多個i-PDU收集到一個容器PDU中。然后，這個容器PDU通過PduR作為一個（大的）I-PDU傳輸。這種方式可以利用新總線系統(tǒng)的優(yōu)勢，允許與更小的I-PDU大小（通常是8字節(jié)）一起有效地使用帶寬。

3.2?I-PDU多路復(fù)用I-PDU Multiplexing

3.2.1 Definitions and Layout

一個多路復(fù)用的I-PDU由一個靜態(tài)部分和一個動態(tài)部分組成，其中靜態(tài)部分由零個或多個信號或信號組組成。動態(tài)部分由選擇器字段和一個或多個信號或信號組組成，請參見圖3。I-PDU的動態(tài)部分可與C語言的union相比較。根據(jù)I-PDU內(nèi)的選擇器字段的值，將選擇I-PDU的實際布局。

靜態(tài)部件和動態(tài)部件的位置可根據(jù)I-PDU進行配置。靜態(tài)部分和動態(tài)部分可以被細分為不同的部分。對于每個多路復(fù)用的I-PDU，只能定義一個選擇器字段。選擇器字段的值定義了如何解釋I-PDU的動態(tài)部分的內(nèi)容。選擇器字段具有在1到16個連續(xù)位之間的可配置大小，其位置可以通過配置來定義。

pdu的多路復(fù)用最初來自于CAN，但它并不局限于這個通信系統(tǒng)。在AUTOSAR體系結(jié)構(gòu)中，位于接口層（通信硬件抽象）上方的PDU路由器分層，因此該特性可以用于所有總線系統(tǒng)，可以由PDU路由器處理，例如FlexRay。

3.2.2通用功能描述 General

靜態(tài)部分有一個COM I-PDU，一個復(fù)用IpduM I-PDU的動態(tài)部分的每個布局有一個COM I-PDU，因此IpduM最多組合兩個COM的I-PDU。

IpduM模塊不應(yīng)設(shè)置選擇器字段。選擇器字段的字節(jié)序通過IpduMByteOrder參數(shù)配置。

IpduM模塊依賴于COM模塊的配置。對于每個動態(tài)布局，都需要在COM中配置一個I-PDU。這樣的i-pdu已經(jīng)必須包含正確的選擇器字段值。COM中的選擇器字段值可以通過配置為信號來初始化，這些信號用init值初始化，但在初始化后不會寫入。

應(yīng)允許優(yōu)化從IpduM模塊到PDU路由器模塊的Rx-和Tx-確認路徑，直接從IpduM模塊調(diào)用COM API，而不包括PduR模塊。這個功能通過配置IpduMRxDirectComInvocation參數(shù)可以實現(xiàn)。

3.2.3模塊初始化 Initialization

IpduM_Init函數(shù)完成IpduM模塊的初始化。

對于通過IpduM模塊的I-PDU數(shù)據(jù)傳輸路徑，在IpduM模塊內(nèi)分配了一個緩沖區(qū)。這個緩沖區(qū)需要初始化，因為它可能在COM模塊完全填充數(shù)據(jù)之前傳輸。此緩沖區(qū)的初始化數(shù)據(jù)來自COM模塊配置的初始值，如下：

1）IpduM應(yīng)使用配置的模式IpduMIPduUnusedAreasDefault.初始化其內(nèi)部傳輸緩沖區(qū)。

2）動態(tài)部分的信號的初始值應(yīng)參考 COM I-PDU (IpduMInitialDynamicPart -> IpduMTxDynamicPart -> IpduMTxDynamicPduRef所應(yīng)用的PDU的初始值。

3）靜態(tài)部分的信號的初始值應(yīng)參考 COM I-PDU (IpduMTxStaticPart -> IpduMTxStaticPduRef所應(yīng)用的PDU的初始值。

選擇器字段包含在初始動態(tài)部分的一個段中，因此被隱式地初始化。

為了進行優(yōu)化，緩沖區(qū)可以在配置時計算出初始位模式，然后在運行時進行復(fù)制。

3.2.4 數(shù)據(jù)傳輸Transmission

在COM內(nèi)部，靜態(tài)部分有獨立的I-PDU，多路I-PDU的每個動態(tài)部分都有一個。

靜態(tài)部分和動態(tài)部分在COM中被視為單獨的I-PDU，并且它們有自己的i-pduid。

對于多路I-PDU，IpduM應(yīng)將對應(yīng)的兩個代表相關(guān)靜態(tài)部分和最后接收到的動態(tài)部分的COMI-PDU合并為一個I-PDU，具有一個新的唯一I-PDU ID。IpduM將將這個新的IpduM I-PDU發(fā)送到PduR模塊。

所有的控制功能，如COMI-pdu的deadline monitoring和 update-bit評估，必須由COM層來完成。

Transmission request

IpduM模塊提供了一個IpduM_Transmit功能，使PDU路由器能夠啟動I-PDU的傳輸。

功能IpduM_Transmit應(yīng)使用相關(guān)的靜態(tài)和動態(tài)部分組裝多路復(fù)用的I-PDU。

每個輸出的I-PDU都有一個初始值，因此，在靜態(tài)和動態(tài)部件從COM發(fā)送到IpduM之前，IpduM模塊傳輸I-PDU，則傳輸由配置定義的值。

只要沒有接收到IpduM I-PDU的傳輸確認（無論結(jié)果如何），函數(shù)IpduM_Transmit將返回E_NOT_OK。

如果多路I-PDU僅通過更新動態(tài)或靜態(tài)部分來觸發(fā)發(fā)送，那么如果在兩次傳輸之間進行多次更新，非觸發(fā)部分可能會被覆蓋。

Transmission trigger

IpduM模塊通過兩個來自PduR模塊的兩個傳輸請求來接收多路I-PDU的靜態(tài)和動態(tài)部分。

IpduM模塊應(yīng)可配置為向PduR發(fā)送針對新的多路I-PDU的傳輸請求：

1）接收到I-PDU的靜態(tài)部分信號

2）接收到I-PDU的動態(tài)部分信號

3）接收到I-PDU的靜態(tài)或者動態(tài)部分信號

4）在觸發(fā)傳輸時，由于接收到任何此I-PDU（IpduMTxTriggerMode None）而不觸發(fā)傳輸。

四種觸發(fā)條件/模式允許通過COM發(fā)送的單個I-PDU的傳輸模式來控制新組裝的I-PDU的傳輸模式。

并不是所有的四種觸發(fā)條件/模式都保證了多路復(fù)用i - pdu不同實例之間連續(xù)傳輸?shù)淖钚⊙舆t時間，因為如果傳輸是由靜態(tài)和動態(tài)部分觸發(fā)的，或者僅由動態(tài)部分觸發(fā)，COM不會考慮最小延遲時間。COM將靜態(tài)部分和不同的動態(tài)部分視為不相關(guān)的獨立i - pdu。

如果I-PDU只因為下層的觸發(fā)傳輸而被發(fā)送出去，則需要配置“因為接收到任何東西而不觸發(fā)傳輸”。使用API IpduM_TriggerTransmit，較低的層可以觸發(fā)I-PDU的發(fā)送。

當(dāng)IpduMTxTriggerMode為None時，下級通過IpduM_TriggerTransmit觸發(fā)傳輸協(xié)議時，IpduMTxConfirmationPduId需要配置，因為IpduM_TriggerTransmit時，IpduMTxConfirmationPduId也用于解析I-PDU。

Just-In-Time update of parts

有時，IpduM模塊可能不只是發(fā)送本地存儲的部分，因為這些部分可能包含過時的信息，例如更新位。因此，IpduM支持每個部分都有一個可配置的即時更新機制。

如果一個部分的更新觸發(fā)了多路I-PDU的傳輸，而第二個部分的IpduMJitUpdate配置為true，則IpduM模塊必須先通過PduR_IpduMTriggerTransmit更新第二個部分，然后再通過PduR_IpduMTransmit發(fā)送多路I-PDU。

如果通過IpduM_TriggerTransmit請求一個多路復(fù)用I-PDU的內(nèi)容，IpduM模塊在返回多路復(fù)用I-PDU的內(nèi)容之前，必須更新所有配置了IpduMJitUpdate的部分。

如果IpduM需要及時更新動態(tài)部分，則更新上層發(fā)送的最新動態(tài)部分，如果之前沒有發(fā)送動態(tài)部分，則更新IpduMInitialDynamicPart引用的動態(tài)部分。

如果一個多路I-PDU的更新觸發(fā)了一個多路I-PDU的傳輸，而第二個部分的IpduMJitUpdate配置為true，那么如果通過PduR_IpduMTriggerTransmit的jit更新請求返回E_NOT_OK，則該多路I-PDU將不發(fā)送。

如果通過IpduM_TriggerTransmit請求多路I-PDU的內(nèi)容，并且IpduMJitUpdate為任何多路部分配置為true，如果通過PduR_IpduMTriggerTransmit的任何JIT-update re請求返回E_NOT_OK, IpduM_TriggerTransmit將返回E_NOT_OK。

Transmission confirmation

根據(jù)PDU Router中i -PDU的配置，PDU Router ac向IpduM模塊發(fā)送傳輸確認。

如果IpduM接收到一個特定IpduM I-PDU的TxConfirmation，它應(yīng)該將這個確認轉(zhuǎn)換為COM I-PDU的相應(yīng)確認，這些確認包含在最后發(fā)出的多路復(fù)用IpduM I-PDU中。

根據(jù)IpduMTxDynamicConfirmation和IpduMTxStaticConfirmation的配置，對于一個發(fā)送請求，IpduM將向COM傳遞零、一個或兩個確認。給上層的確認次數(shù)不依賴于IpduMTxTriggerMode。

Examples:

1）如果對應(yīng)的IpduMTxRequest的IpduMTxDynamicConfirmation和IpduMTxStaticConfirmation都不配置為true，則不生成COM確認。

2）如果IpduMTxStaticConfirmation配置為true，而IpduMTxDynamic確認配置為false(反之亦然)，則只生成一個COM確認。

3）如果IpduMTxStaticConfirmation和IpduMTxDynamicConfirmation都配置為true，則會生成兩個COM確認;到表示所述靜態(tài)部分的I-PDU和表示所述動態(tài)部分的I-PDU。

如果生成了兩個傳輸確認，它們顯然是相等的，因為它們來自同一個I-PDUM傳輸確認。

3.2.5 數(shù)據(jù)接收Reception

通信硬件抽象(CAN接口、Lin接口、FlexRay接口)接收到的每個I-PDU都被發(fā)送給PDU路由器。PDU Router將多路i -PDU路由到IpduM模塊。IpduM模塊將多路復(fù)用I-PDU的靜態(tài)部分和動態(tài)部分分開路由到它們的目的地。

在配置時，已知傳入的I-PDU id對應(yīng)于配置了靜態(tài)部分的多路復(fù)用I-PDU。I-PDU ID是判斷是否存在靜態(tài)部件所需的全部信息。

由于所有多路復(fù)用i - pdu都包含一個動態(tài)部分，因此該部分總是必須被路由。

沒有處理或通知錯誤配置的部件的要求。因此，如果接收到的I-PDU包含未在ECU上配置為接收的段，它們將被無聲地忽略。此外，如果一個I-PDU配置了PduLength為0，它也將被無聲地忽略，因為沒有任何有意義的處理可以配置。

這種情況可能發(fā)生在網(wǎng)關(guān)設(shè)置中，如果一個多路復(fù)用I-PDU總是被PDU路由器路由到另一個總線上，但在一個動態(tài)部分中包含一個必須傳遞給應(yīng)用程序的信號。在這種情況下，多路復(fù)用PDU也必須路由到IpduM。

3.2.6 元數(shù)據(jù)處理Metadata handling

僅當(dāng)“IpduMMetaDataSupport”配置為“true”時，本節(jié)要求才適用。

如果IpduMTxTriggerMode配置為與NONE不同的值，IpduM將使用觸發(fā)部分的MetaData發(fā)送多路I-PDU。

如果配置了“IpduMTxTriggerMode”為“NONE”，則IpduM發(fā)送多路I-PDU時，將使用上次更新部分的元數(shù)據(jù)。

在接收端，IpduM應(yīng)將接收到的元數(shù)據(jù)連同所有解復(fù)用部分一起轉(zhuǎn)發(fā)。

3.3Multiple-PDU-to-Container handling

IpduM支持將多個i -PDU映射到一個Container PDU。從PduR的角度來看，包含式pdu和容器式pdu都是普通的pdu。容器布局既可以在包含的i - pdu前使用標頭動態(tài)定義，也可以不使用標頭靜態(tài)定義，但為包含的i - pdu定義靜態(tài)位置。

IpduM依賴于PduR被配置為將映射到Container-PDU的發(fā)送pdu轉(zhuǎn)發(fā)給IpduM，并將接收到的container pdu轉(zhuǎn)發(fā)給IpduM。

3.3.1 Dynamic Container Layout

在動態(tài)容器PDU中，IpduM應(yīng)將包含的I-PDU的頭置于包含的I-PDU的前面。

對于動態(tài)容器PDU，容器PDU中所包含的I-PDU的位置沒有配置，因此任意一個包含I-PDU的位置是由負載(DLC)的長度和前面(之前添加的)包含I-PDU的頭來決定的。

容器PDU中i -PDU的數(shù)量受容器PDU最大大小的限制。

容器PDU中i -PDU的順序?qū)⒈槐Ａ簟Ｍㄟ^這種方式，所有受保護的i -PDU都按照它們被放入con tainer PDU中的相同順序被提取。

IpduM支持動態(tài)容器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內(nèi)混合頭部大小。

每個I-PDU報頭由ID字段和length字段組成，字節(jié)順序由IpduMHeaderByteOrder決定。

動態(tài)容器PDU中所含i -PDU的頭和有效載荷的放置應(yīng)該是連續(xù)的，沒有任何間隙。

原理:這允許通過考慮報頭大小和有效載荷長度(來自報頭的DLC)在容器PDU上迭代。

這必須通過容器收集算法的實現(xiàn)來確保，因為包含的i -PDU在容器PDU中沒有專用的(配置的)位置。

3.3.2Static Container Layout

當(dāng)將包含的I-PDU添加到尚未觸發(fā)的容器PDU中時，如果將IpduMContainedTxPduTrigger設(shè)置為IPDUM_TRIGGER_ALWAYS，則容器PDU立即被觸發(fā)。

當(dāng)IpduMContainerTxFirstContainedPduTrigger參數(shù)設(shè)置為TRUE時，IpduM將第一個包含的I-PDU添加到容器PDU中，需要調(diào)用PduR_IpduMTransmit。

原理:通過這種方式，對時間觸發(fā)總線請求傳輸。

3.3.3 Transmission

當(dāng)將第一個包含的I-PDU添加到容器PDU中，且容器PDU的IpduMContainerTxSendTimeout或包含的I-PDU的IpduMCon (IpduMCon) tainedTxPduSendTimeout配置為大于零時，IpduM模塊將啟動容器PDU的傳輸定時器。定時器初始化為IpduMContainerTxSendTimeout和IpduMContainedTxPduSendTimeout中較小的非零值。

直到容器PDU被取走，或者除非容器PDU的最大大小沒有超過，否則可以添加分配給該容器的請求i -PDU。

當(dāng)一個包含的I-PDU被添加到容器PDU中時，如果包含的I-PDU的超時時間小于容器PDU的剩余時間，則容器PDU的傳輸計時器將被更新為包含的I-PDU的超時時間(IpduMContainedTxPduSendTimeout)。

當(dāng)容器PDU的傳輸定時器結(jié)束時，容器PDU將被觸發(fā)。

當(dāng)Container PDU被觸發(fā)時，IpduM將調(diào)用PduR_IpduMTransmit。

將容器PDU傳遞給PduR時，參數(shù) (PduInfoPtr)應(yīng)包含一個指向已組裝的容器PDU (SduDataPtr)的指針，并包含SduLength (SduLength)的總長度。

Queueing

如果一個容器PDU的多個實例必須由IpduM保存，除了當(dāng)前的數(shù)據(jù)之外，最多可以存儲IpduMContainerQueueSize實例。當(dāng)前實例是當(dāng)前包含i -PDU的容器PDU的一個實例。在該實例被排隊或復(fù)制到下層之后，即在根據(jù)IpduMContainerTxTriggerMode的配置調(diào)用TriggerTransmit或Transmit API之后，不能再將包含的i - pdu添加到該實例中。

如果PduR_IpduMTransmit已經(jīng)返回E_NOT_OK，在下一次調(diào)用IpduM_MainFunctionTx時，將重復(fù)相同的傳輸請求。與此同時，該Container PDU的實例處于排隊狀態(tài)。

在為該容器PDU的下一個實例調(diào)用PduR_IpduMTransmit之前，IpduM應(yīng)等待傳輸確認(無論結(jié)果如何)。

IpduM模塊在這里依賴于為下層的Container PDU配置的傳輸確認。

如果收到該容器PDU的傳輸確認，IpduM將在下次調(diào)用IpduM_MainFunctionTx時最遲為該容器PDU的下一個舊實例調(diào)用PduR_IpduMTransmit。

如果IpduMContainerTxTriggerMode被設(shè)置為IPDUM_DIRECT，并且PduR_IpduMTransmit為該容器PDU返回E_OK, IpduM將從隊列中刪除該實例。

在這種情況下，如果使用CanIf中的隊列，Container-PDU的實例可能會丟失，因為較新的實例可能會覆蓋之前的實例。這種最后是最好的行為在這種情況下可能不可取。

如果IpduM接收到一個特定的包含PDU的TxConfirmation，它應(yīng)該將此確認轉(zhuǎn)換為那些包含IpduMContainedTxPduConfirmation設(shè)置為TRUE的I-PDU的相應(yīng)確認，并且包含在容器I-PDU的最后一個發(fā)送實例中。如果包含的相同I-PDU出現(xiàn)多次，則會導(dǎo)致多個txconfirmation。

如果創(chuàng)建一個Container PDU的新實例超過了IpduMContainerQueueSize，那么舊的實例將被丟棄。如果沒有配置IpduMContain erQueueSize，則丟棄本地實例。在這兩種情況下，IPDUM_E_QUEUEOVFL將通過Det_ReportRuntimeError報告給DET。

如果一個容器PDU實例被TriggerTransmit讀取，它將從隊列中刪除。

Triggered Transmission and Last-is-Best semantics

如果IpduMContainerTxTriggerMode設(shè)置為IpduM_TriggerTransmit, IpduM將保留并提供緩沖數(shù)據(jù)，直到調(diào)用IpduM_TriggerTransmit來獲取數(shù)據(jù)。

如果IpduMContainerTxTriggerMode設(shè)置為IpduM_TriggerTransmit，則IpduM_TriggerTransmit將復(fù)制隊列中最古老的container PDU實例。如果隊列為空或不存在，則復(fù)制Container PDU的當(dāng)前實例。如果容器PDU的當(dāng)前實例為空/不存在(不存在)，則由IpduM_TriggerTransmit返回E_NOT_OK。

對于被包含的I-PDU，如果ipdumcontainedtxducollec tionSemantics設(shè)置為IPDUM_COLLECT_LAST_IS_BEST, IpduM在將容器I-PDU傳輸?shù)较聦又埃瑢⑹褂肞duR_IpduMTriggerTransmit從上層獲取PDU數(shù)據(jù)。

雖然將ipdumcontainedtxducollectionsemantics IPDUM_COLLECT_LAST_IS_BEST與IpduMContainerTxTrigger Mode IPDUM_TRIGGERTRANSMIT結(jié)合使用似乎很自然，但它也可以與IPDUM_DIRECT結(jié)合使用。

一旦一個包含的I-PDU被配置為使用最后是最好的語義，用戶就會接受這個包含的I-PDU的所有實例/值不一定在網(wǎng)絡(luò)上都是可見的。另一方面，隊列收集語義保證所包含I-PDU的每個實例/值在線路上都是可見的。

3.3.4Transmission of Dynamic Containers

由于以下要求，IpduM將確保一個包含的I-PDU(相同的PDU-ID)的實例以與它們傳遞給IpduM的順序完全相同的順序傳輸(傳遞給容器pdu中的PduR)。

當(dāng)一個ipdumcontainedtxducolletionsemantics設(shè)置為IPDUM_COLLECT_QUEUED的I-PDU通過IpduM_Transmit傳遞給IpduM時，IpduM將識別相關(guān)的容器PDU并將包含的I-PDU附加到其有效負載，即使容器PDU中已經(jīng)存在包含的I-PDU的先前實例。

通過這種方式，一個Container PDU可以包含同一個I-PDU的多個實例。產(chǎn)生的行為類似fifo，以保持正在傳輸?shù)腎-PDU實例的順序。因此，接收IpduM的上層可以實現(xiàn)最后是最好的語義或FIFO（ last-is-best or FIFO）語義。

如果一個包含的I-PDU已經(jīng)被添加到尚未觸發(fā)的容器PDU中，并且如果產(chǎn)生的有效載荷大于IpduMContain erTxSizeThreshold，則容器PDU將被觸發(fā)。

如果IpduMContainerTxTriggerMode設(shè)置為IPDUM_DIRECT，添加一個包含的I-PDU將超過容器I-PDU的最大大小，則首先觸發(fā)容器PDU。所包含的I-PDU應(yīng)添加到Container PDU的新實例中。

如果IpduMContainerTxTriggerMode設(shè)置為IPDUM_TRIGGERTRANSMIT，添加包含的I-PDU將超過容器PDU的最大大小，則首先將容器PDU排隊。然后將包含的I-PDU添加到Container PDU的新實例中。

包含的i - pdu將使用IpduMContainerTxTrigger Mode = IPDUM_TRIGGERTRANSMIT添加到容器pdu，只要它們既沒有滿也沒有排隊。

當(dāng)一個Container PDU被TriggerTransmit觸發(fā)或提取后，IpduM將計算Container PDU的整體大小。總大小由包含的i - pdu的所有有效負載之和加上相應(yīng)報頭的總長度構(gòu)成。其結(jié)果應(yīng)為容器PDU的有效載荷大小。

Triggered Transmission and Last-is-Best semantics

如果包含ipdumcontainedtxducollectionsemantics設(shè)置為IPDUM_COLLECT_LAST_IS_BEST的i - pdu, IpduM模塊會在發(fā)送前更新這些i - pdu。如果這些包含的i - pdu具有動態(tài)大小，則可能發(fā)生容器大小不足以容納所有包含的i - pdu，如果已過期的i - pdu的總體大小增加。

如果使用IpduMCon tainedtxducollectionsemantics IPDUM_COLLECT_LAST_IS_BEST更新包含的I-PDU，并且container的大小不足以容納一個包含的I-PDU，那么這個包含的I-PDU和所有后續(xù)的I-PDU將被轉(zhuǎn)移到下一個容器實例的開頭。

為了保持包含的i - pdu的順序，即使當(dāng)前容器中有足夠的空間，也需要轉(zhuǎn)移所有后續(xù)包含的i - pdu。

當(dāng)將包含的i - pdu存儲到容器pdu中時，IpduM應(yīng)保留包含的i - pdu傳遞給IpduM的順序。也就是說，第一個傳遞的包含I-PDU被放置在容器的開頭，以此類推。如果一個包含ipdumcontainedtxducollectionsemantics設(shè)置為IPDUM_COLLECT_LAST_IS_BEST的I-PDU被多次傳遞，IpduM將只在它第一次出現(xiàn)的位置存儲它一次。

如果PduR_IpduMTriggerTransmit為包含的I-PDU返回E_NOT_OK, IpduM將隱去包含的I-PDU。相關(guān)的容器PDU無論如何都將傳輸，而不包含省略的I-PDU。在跳過的I-PDU后面的所有包含I-PDU都將按照包含省略的I-PDU(包括其頭部)的大小向上移動。

3.3.5 Transmission of Static Containers

對于靜態(tài)容器布局的Container PDU，如果IpduMContainerTxTriggerMode設(shè)置為IPDUM_DIRECT，則當(dāng)所有包含的i -PDU被上層更新時，IpduM將觸發(fā)Container PDU。

由于靜態(tài)容器可能包含未更新的包含i - pdu，因此在接收端有方法檢測包含i - pdu的當(dāng)前狀態(tài)。為包含的i - pdu或unsed區(qū)域的默認模式配置更新位。

如果所包含的I-PDU配置了Ipdu (PDU)的MUpdateBitPosition，當(dāng)且僅當(dāng)所包含的I-PDU被成功更新時，IpduM應(yīng)確保該I (PDU)的更新位被設(shè)置。

如果靜態(tài)容器配置了IpduM(節(jié)點)的UnusedAreasDefault，則IpduM應(yīng)確保在容器PDU發(fā)送之前，容器(節(jié)點)的所有未更新區(qū)域都被設(shè)置為IpduMUnusedAreasDefault值。

這允許IpduM處理靜態(tài)容器中包含的具有動態(tài)長度的i - pdu。但是，如果SWC或發(fā)送ip設(shè)置了IpduMUnusedAreasDefault-value，則接收ip無法檢測到。因此，總是會接收到完整的，最終被填充的包含I-PDU。

必須注意到，一些總線(如CAN-FD和FlexRay)不能傳輸任意長度的pdu，可能會用自己的默認值將發(fā)送的I-PDU填充到下一個可能的長度。因此，IpduM的UnusedAreasDefault值的配置應(yīng)該與總線特定的填充模式保持一致。

3.3.6 Reception

如果“IpduMContainerPduProcessing”設(shè)置為“ IPDUM_PROCES_SING_IMMEDIATE”，則對接收到的容器pdu進行“IpduM_RxIndication”的處理。否則，它將被延遲到下一次對IpduM_MainFunctionRx的調(diào)用。所有延期的集裝箱pdu應(yīng)按照接收順序進行處理。

如果通過調(diào)用IpduM_RxIndication，容器PDU被重新接收，包含的i -PDU將被提取。

如果容器PDU的IpduMContainerRxAcceptCon tainedPdu設(shè)置為IPDUM_ACCEPT_CONFIGURED, IpduM將只期望并匹配IpduMContainedRxIn ContainerPduRef中引用容器PDU的包含的i -PDU。

每個包含的I-PDU通過PduR_IpduMRxIndication通知PduR。IpduM應(yīng)按照容器PDU中i -PDU的位置順序指示所包含的i -PDU。

Queueing

如果收到Container PDU，且“IpduMContainerPduPro PDU處理”設(shè)置為“IPDUM_PROCESSING_DEFERRED”，則該Container PDU將進入隊列。

如果接收到的容器PDU的新實例超過了IpduMContainerQueueSize，則舊實例將被丟棄，并通過Det_ReportRuntimeError將IPDUM_E_QUEUEOVFL報告給DET。

3.3.7 Reception of Dynamic Containers

對于每個包含的I-PDU，其頭部應(yīng)使用的ID用于標識對應(yīng)的I-PDU:

. 如果接收到的容器使用長頭(IpduMContainerHeaderSize = IPDUM_HEADERTYPE_LONG)，則該ID將與IpduMCon (IpduMCon)的長頭(IpduMCon)進行比較。

. 如果接收到的容器使用短頭(IpduMContainerHeaderSize = IPDUM_HEADERTYPE_SHORT)，則該ID將與IpduMContainedRxPduShortHeaderId進行比較。

如果對于容器PDU, IpduMContainerRxAcceptCon tainedPdu設(shè)置為IPDUM_ACCEPT_ALL, IpduM將期望并匹配所有受控的i -PDU，而不依賴于IpduMContainedRxInContainerPduRef。

如果提取的包含I-PDU不能根據(jù)其ID匹配，它將被默默地丟棄。

對于每個包含的I-PDU，其頭應(yīng)使用中給出的長度為對應(yīng)的I-PDU的長度。

當(dāng)處理接收到的容器PDU并檢測到包含ID 0的報頭時，對該容器PDU的處理應(yīng)停止，其余字節(jié)應(yīng)被忽略。

原理:頭ID為0意味著容器PDU已被填充字節(jié)填充，不再包含進一步的數(shù)據(jù)。

3.3.8 Reception of Static Containers

為了讓接收IpduM模塊能夠確定接收到的靜態(tài)容器中的哪些PDU已經(jīng)在發(fā)送端被更新，可以為每個包含的I-PDU配置額外的更新信息，即容器PDU中的PDU更新位。

對于接收到的包含I-PDU，如果配置了更新位，則IpduM模塊只對其進行處理，并將其指示給上層。

上述需求會導(dǎo)致靜默地忽略已配置但未設(shè)置更新位的包含i - pdu。

未配置更新位的i - pdu始終被處理并指示給上層。假設(shè)它們總是有效的。

3.3.9 Errorhandling

有些總線系統(tǒng)不可能為傳輸?shù)腖-PDU設(shè)置任意大小(例如canfd)。容器PDU的有效負載長度可以從包含的報頭中得到。因此，與Container PDU實際長度的差值可視為填充。

假設(shè)底層總線模塊的配置使填充值不構(gòu)建有效的報頭。

當(dāng)處理接收到的容器PDU并檢測到有效載荷長度超過容器剩余字節(jié)的報頭時，對該容器PDU的處理應(yīng)停止并忽略剩余字節(jié)。另外，IPDUM_E_HEADER需要通過Det_ReportRuntimeError上報給DET。

有效負載長度大于剩余字節(jié)的標頭（header）無效。在它后面不會再有頭（header）了。

如果Container PDU中剩余的字節(jié)小于配置的IpduMContainerHeaderSize，剩余的字節(jié)將被忽略。

當(dāng)處理一個IpduMContainerHeaderSize設(shè)置為IPDUM_HEADERTYPE_NONE的容器PDU時，IpduM將忽略所有根據(jù)其配置不包含或不完全包含在接收到的容器PDU中的PDU。這些包含的i - pdu不能顯示給上層。如果配置了開發(fā)錯誤檢測，IPDUM_E_CONTAINER將通過Det_ReportError報告給DET。

3.3.10 Metadata handling

如果Container PDU支持元數(shù)據(jù)，則IpduM在發(fā)送Container PDU時應(yīng)使用從包含的i -PDU中最后收集的元數(shù)據(jù)。

如果IpduM接收到帶有元數(shù)據(jù)的容器PDU，則IpduM應(yīng)將容器PDU的元數(shù)據(jù)連同所有包含支持元數(shù)據(jù)的I-PDU一起轉(zhuǎn)發(fā)。

IpduM不重新排列元數(shù)據(jù)。因此，它只支持分配給相同容器pdu的包含i - pdu，這些容器pdu沒有元數(shù)據(jù)或具有相同的元數(shù)據(jù)類型。

編輯：黃飛

?