CAN通信中的UB是什么？

什么是更新位？

為了幫助信號或信號組的接收端來識別發(fā)送端是否在發(fā)送前更新了信號或信號組的數(shù)據(jù)，AUTOSAR COM模塊整出了“更新位”（Update Bit），它表征的是發(fā)送端RTE在通過I-PDU傳遞給PDUR前，信號是否更新。

如果傳輸模式設(shè)置為“DIRECT”，那就沒有更新位一說了。

通過配置發(fā)送端和接收端，每個信號或信號組都可以分配一個更新位，來表征其更新狀態(tài)，配置參數(shù)為 ComUpdateBitPosition ，因此可以知道，信號和對應(yīng)的更新位在相同I-PDU內(nèi)，即在CAN總線上，位于相同一幀CAN報文中。當(dāng)然，信號或信號組也可以不配置更新位。

拿發(fā)送端來看。

當(dāng)RTE調(diào)用Com_SendSignal函數(shù)來更新信號值（或者調(diào)用Com_SendSignalGroup更新信號組）時，AUTOSAR COM模塊將會將UB置為1。

當(dāng)PduR_ComTransmit函數(shù)將I-PDU中的函數(shù)發(fā)送出去并反饋E_OK后，AUTOSAR COM模塊將會把信號或信號組對應(yīng)的UB清為0，此時需要將參數(shù)數(shù)ComTxIPduClearUpdateBit配置為傳輸（Transmit）。

當(dāng)PduR_ComTransmit函數(shù)將I-PDU中的函數(shù)發(fā)送出去，反饋E_OK并成功確認后，AUTOSAR COM模塊將會把信號或信號組對應(yīng)的UB清為0，此時，參數(shù)ComTxIPduClearUpdateBit 需要配置為確認（Confirmation）。

當(dāng)*** Com_TriggerTransmit*** 函數(shù)成功請求I-PDU的信號后，AUTOSAR COM模塊將會把信號或信號組對應(yīng)的UB清為0，此時，參數(shù)ComTxIPduClearUpdateBit需要配置為觸發(fā)傳輸（TriggerTransmit）。

當(dāng)然，在通信矩陣的說明文檔制作之時，就應(yīng)該規(guī)定好信號或信號組合對應(yīng)更新位的關(guān)系。比如，在制作dbc文件時，要標(biāo)注報文消息中信號A和對應(yīng)的更新位A _UB，以及信號組G和對應(yīng)信號組的更新位G_UB。同時，信號和對應(yīng)更新位一定要在相同消息中傳遞。如果dbc將一個信號的更新位單獨拿出來，做成了兩個信號，那么配置工具將無法進行更新位的配置。也正因為更新位是定義在相同一幀消息報文中，所以通信矩陣確認定義好，根據(jù)通信矩陣的定義配置即可。

**對于更新位來說，0是未更新，1是已更新。

**

那么，使用UB有什么好處呢？

試想，車內(nèi)各控制器節(jié)點通過CAN傳遞數(shù)據(jù)。假設(shè)PEPS節(jié)點通過一條報文消息將起動請求信號A傳遞給TCU節(jié)點，但并不想把點火開關(guān)信號B傳遞給TCU，從網(wǎng)絡(luò)布置最大化來看，剛好A和B處在同一幀報文中，TCU在接收到報文消息后判斷是否響應(yīng)B。

有了UB以后，就可以輕松處理該場景了。TCU接收到B后先判斷B_UB是否置1，PEPS顯然不希望將B_UB置1，這時，PEPS就可以一直保持B_UB一直為0，TCU就無法更新接收到的B信號了。CAN矩陣不需要制作很多版本，即滿足了歸一化的需求，也實現(xiàn)了不同項目的個性化配置。