1.IpduM功能簡介

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

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

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

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

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

2.1RTE (BSW Scheduler)

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

2.2PDU Router

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

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

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

3）發(fā)送報(bào)文確認(rèn)

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

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

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

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

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

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

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

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

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

2.3COM

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

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

3.IpduM功能詳解

3.1?功能概述

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

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

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

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

3.2.1 Definitions and Layout

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

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

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

3.2.2通用功能描述 General

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

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

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

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

3.2.3模塊初始化 Initialization

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

對于通過IpduM模塊的I-PDU數(shù)據(jù)傳輸路徑，在IpduM模塊內(nèi)分配了一個(gè)緩沖區(qū)。這個(gè)緩沖區(qū)需要初始化，因?yàn)樗赡茉贑OM模塊完全填充數(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)部分的一個(gè)段中，因此被隱式地初始化。

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

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

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

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

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

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

Transmission request

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

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

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

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

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

Transmission trigger

IpduM模塊通過兩個(gè)來自PduR模塊的兩個(gè)傳輸請求來接收多路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ā)傳輸時(shí)，由于接收到任何此I-PDU（IpduMTxTriggerMode None）而不觸發(fā)傳輸。

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

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

如果I-PDU只因?yàn)橄聦拥挠|發(fā)傳輸而被發(fā)送出去，則需要配置“因?yàn)榻邮盏饺魏螙|西而不觸發(fā)傳輸”。使用API IpduM_TriggerTransmit，較低的層可以觸發(fā)I-PDU的發(fā)送。

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

Just-In-Time update of parts

有時(shí)，IpduM模塊可能不只是發(fā)送本地存儲的部分，因?yàn)檫@些部分可能包含過時(shí)的信息，例如更新位。因此，IpduM支持每個(gè)部分都有一個(gè)可配置的即時(shí)更新機(jī)制。

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

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

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

如果一個(gè)多路I-PDU的更新觸發(fā)了一個(gè)多路I-PDU的傳輸，而第二個(gè)部分的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ā)送傳輸確認(rèn)。

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

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

Examples:

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

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

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

如果生成了兩個(gè)傳輸確認(rèn)，它們顯然是相等的，因?yàn)樗鼈儊碜酝粋€(gè)I-PDUM傳輸確認(rèn)。

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

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

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

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

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

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

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

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

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

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

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

3.3Multiple-PDU-to-Container handling

IpduM支持將多個(gè)i -PDU映射到一個(gè)Container PDU。從PduR的角度來看，包含式pdu和容器式pdu都是普通的pdu。容器布局既可以在包含的i - pdu前使用標(biāo)頭動態(tài)定義，也可以不使用標(biāo)頭靜態(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的位置沒有配置，因此任意一個(gè)包含I-PDU的位置是由負(fù)載(DLC)的長度和前面(之前添加的)包含I-PDU的頭來決定的。

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

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

IpduM支持動態(tài)容器pdu的兩種不同的報(bào)頭大小（ IpduMContainerHeaderSize）：

. IPDUM_HEADERTYPE_SHORT with 24 bit ID and 8 bit length

. IPDUM_HEADERTYPE_LONG with 32 bit ID and 32 bit length

頭大小通過IpduMContainerHeaderSize配置每個(gè)Container PDU。因此，它對整個(gè)容器PDU都有效。不支持在一個(gè)Con?tainer PDU內(nèi)混合頭部大小。

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

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

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

這必須通過容器收集算法的實(shí)現(xiàn)來確保，因?yàn)榘膇 -PDU在容器PDU中沒有專用的(配置的)位置。

3.3.2Static Container Layout

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

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

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

3.3.3 Transmission

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

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

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

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

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

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

Queueing

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

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

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

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

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

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

在這種情況下，如果使用CanIf中的隊(duì)列，Container-PDU的實(shí)例可能會丟失，因?yàn)檩^新的實(shí)例可能會覆蓋之前的實(shí)例。這種最后是最好的行為在這種情況下可能不可取。

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

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

如果一個(gè)容器PDU實(shí)例被TriggerTransmit讀取，它將從隊(duì)列中刪除。

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ù)制隊(duì)列中最古老的container PDU實(shí)例。如果隊(duì)列為空或不存在，則復(fù)制Container PDU的當(dāng)前實(shí)例。如果容器PDU的當(dāng)前實(shí)例為空/不存在(不存在)，則由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é)合使用。

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

3.3.4Transmission of Dynamic Containers

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

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

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

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

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

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

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

當(dāng)一個(gè)Container PDU被TriggerTransmit觸發(fā)或提取后，IpduM將計(jì)算Container PDU的整體大小。總大小由包含的i - pdu的所有有效負(fù)載之和加上相應(yīng)報(bào)頭的總長度構(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的大小不足以容納一個(gè)包含的I-PDU，那么這個(gè)包含的I-PDU和所有后續(xù)的I-PDU將被轉(zhuǎn)移到下一個(gè)容器實(shí)例的開頭。

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

當(dāng)將包含的i - pdu存儲到容器pdu中時(shí)，IpduM應(yīng)保留包含的i - pdu傳遞給IpduM的順序。也就是說，第一個(gè)傳遞的包含I-PDU被放置在容器的開頭，以此類推。如果一個(gè)包含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被上層更新時(shí)，IpduM將觸發(fā)Container PDU。

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

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

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

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

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

3.3.6 Reception

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

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

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

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

Queueing

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

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

3.3.7 Reception of Dynamic Containers

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

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

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

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

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

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

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

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

3.3.8 Reception of Static Containers

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

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

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

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

3.3.9 Errorhandling

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

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

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

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

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

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

3.3.10 Metadata handling

如果Container PDU支持元數(shù)據(jù)，則IpduM在發(fā)送Container PDU時(shí)應(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ù)類型。

編輯：黃飛

?