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

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

Autosar通信棧，簡化示意如下：

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

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

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

1、UB概念

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

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

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

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

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

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

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

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

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

如果為某個信號配置UB時，需要思考兩個問題：

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

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

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

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

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

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

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

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

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

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

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

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

3、UB在接收端的處理

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

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

接收處理解讀：

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

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

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

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

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

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

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

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





審核編輯：劉清