如何理解和使用Update bit呢？

隨著汽車智能化發(fā)展，整車通信矩陣越來越復(fù)雜，即：不同電控單元之間需要交互的信息越來越多，這些信息通過報(bào)文（Message）傳輸。

Message中攜帶的信號(hào)（Signal）最終要傳遞給軟件的上層模塊，參與算法處理，之后再將處理后的信息形成Signal發(fā)送出去。

Autosar通信棧，簡(jiǎn)化示意如下：

不管車輛通信變得如何復(fù)雜，均需要確保車輛運(yùn)行的安全性，而車輛是否能按照預(yù)期狀態(tài)工作，離不開控制器對(duì)Signal的及時(shí)響應(yīng)，所以，及時(shí)的獲取Signal狀態(tài)尤為重要。

為了滿足此需求，在Autosar的架構(gòu)中，對(duì)于發(fā)送端（Sender）和接收端（Receiver）設(shè)計(jì)了不同的信號(hào)狀態(tài)處理策略。其中，超時(shí)機(jī)制（Timeout）與信號(hào)更新機(jī)制（UB，Update bit）最為典型。

提示：由于Signal Group UB與Signal UB實(shí)現(xiàn)類似，本文側(cè)重Signal UB的討論。

1、UB概念

UB：表示發(fā)送端（Sender）所發(fā)送信號(hào)（Signal）/信號(hào)組（Signal Groups）數(shù)據(jù)是否有更新，如果發(fā)送端發(fā)送的Signal/Signal Groups有更新，由COM層自動(dòng)置位對(duì)應(yīng)的UB（=1），反之，復(fù)位UB（=0）。

為什么需要用UB位表示Signal/Signal Groups的數(shù)據(jù)有沒有更新呢？假設(shè)如下場(chǎng)景，報(bào)文Message_A包含信號(hào)Signal_A、Signal_B等，Message_A的發(fā)送周期為10ms，而Signal_A的更新周期為30ms，示意如下：

面對(duì)如上的場(chǎng)景，接收端（Receiver）應(yīng)當(dāng)檢測(cè)Sender是否更新過Signal_A的值，以便于Receiver更好的進(jìn)行算法處理。因此，為了表示Signal/Signal Groups數(shù)據(jù)是否有更新，設(shè)計(jì)了UB，UB需要消耗Message中的資源。舉例：設(shè)計(jì)Signal_A_UB信號(hào)用于表示Signal_A數(shù)據(jù)是否更新過。

由于UB需要消耗Message資源，因此，可以根據(jù)工程場(chǎng)景，對(duì)重要信號(hào)進(jìn)行UB配置，對(duì)非重要信號(hào)，不配置UB，即：UB是一個(gè)選配項(xiàng)。同時(shí)，UB本身也是一個(gè)Signal。在如上的表述中，Sender和Receiver如何理解呢？

（一）同一網(wǎng)段Signal傳輸

如果Sender、Receiver在同一個(gè)局域網(wǎng)內(nèi)，兩者之間的信號(hào)傳輸如下所示：

（二）跨網(wǎng)段Signal傳輸

如果Sender、Receiver在不同局域網(wǎng)內(nèi)，兩者之間的信號(hào)傳輸如下所示：

2、UB在發(fā)送端的處理

如果為某個(gè)信號(hào)配置UB時(shí)，需要思考兩個(gè)問題：

1、何時(shí)置位發(fā)送端的UB位？

2、何時(shí)復(fù)位發(fā)送端的UB位？

（一）何時(shí)置位發(fā)送端的UB位？

當(dāng)上層軟件模塊（Upper Layer）需要發(fā)送Signal時(shí)，會(huì)通過RTE（Run-Time Environment）調(diào)用COM層的發(fā)送接口Com_SendSignal()/Com_SendSignaGroup()更新Signal或者Signal Group值，與此同時(shí)，COM模塊自動(dòng)將Signal/Signal Group對(duì)應(yīng)的UB置位，示意如下：

（二）何時(shí)復(fù)位發(fā)送端的UB位？

在Autosar的架構(gòu)設(shè)計(jì)中，何時(shí)復(fù)位發(fā)送端的UB信號(hào)，有三種模式供開發(fā)者選擇：Transmit、Confirmation、TriggerTransmit。而這三種模式的選擇，通過參數(shù)ComTxIPduClearUpdateBit配置。如何理解這三種模式呢？

1、Transmit模式復(fù)位UB

配置參數(shù)ComTxIPduClearUpdateBit = Transmit，當(dāng)COM模塊請(qǐng)求PduR模塊發(fā)送接口PduR_ComTransmit()發(fā)送數(shù)據(jù)，當(dāng)該接口返回E_OK時(shí)，COM模塊復(fù)位UB，具體流程如下：

2、Confirmation模式復(fù)位UB

配置參數(shù)ComTxIPduClearUpdateBit = Confirmation，當(dāng)Message成功發(fā)送到總線以后，從驅(qū)動(dòng)層通過Callback層層向上通知，直到COM模塊收到Message成功發(fā)送到總線的確認(rèn)信息，COM模塊復(fù)位UB，具體流程如下：

3、TriggerTransmit模式復(fù)位UB

此種模式在工程中，不多見，本文不做過多討論。

3、UB在接收端的處理

Receiver成功從總線接收到目標(biāo)Message以后，驅(qū)動(dòng)層通過Callback層層向上通知，直到COM模塊收到Message，PduR模塊通Com_RxIndication()接口將數(shù)據(jù)通知COM某塊，示意如下：

其中，接收到的UB信息在Com_RxIndication()接口中進(jìn)行處理，具體的處理如下所示：

接收處理解讀：

1、當(dāng)Message信息層層向上傳遞到COM模塊時(shí)，Com_RxIndication()處理UB相關(guān)操作，如果在Receiver中配置了I-PDU Callout，則程序進(jìn)行Callout處理，Callout主要進(jìn)行用戶自定義處理。

如果Receiver中未配置I-PDU Callout，則進(jìn)行后續(xù)處理；

2、進(jìn)行UB檢查，如果UB = 0，COM丟棄UB對(duì)應(yīng)的信號(hào)。如果UB = 1，程序進(jìn)行后續(xù)的字節(jié)序轉(zhuǎn)化（針對(duì)跨字節(jié)信號(hào)），Signal路由等操作。

提示：Autosar架構(gòu)中，COM層處理Signal級(jí)別路由，PduR處理PDU（可以看作幀）的路由。

（一）Receiver何時(shí)復(fù)位UB

Receiver處理收到的UB，需要與reception deadline monitor邏輯配合處理，即：如果信號(hào)deadline超時(shí)，則對(duì)應(yīng)信號(hào)的UB位需要復(fù)位（=0）。reception deadlinemonitor屬于選配項(xiàng)，如果信號(hào)沒有配置reception deadlinemonitor，則接收端接收到的UB信號(hào)值會(huì)一直保持上次的接收值。

4、UB對(duì)應(yīng)的工程問題

UB看起來似乎不難，但是，當(dāng)其成為通信棧的一部分時(shí)，可能會(huì)因系統(tǒng)工程的復(fù)雜性，而引發(fā)各種各樣的問題。





審核編輯：劉清