今天这篇文章解答多位同学的疑问：CAN通信中的更新位UB到底是如何起作用的？
对于AUTOSAR中CAN通信不了解的同学，可以回顾以往的文章：
汽车CAN总线详解
AUTOSAR通信篇—AUTOSAR COM模块
AUTOSAR通信篇—PduR模块
AUTOSAR通信篇—CanIf模块
AUTOSAR通信篇—IpduM模块
AUTOSAR通信篇—CANTP模块
AUTOSAR通信之CAN状态管理：CanSM
来，开始讨论今天的问题。
什么是更新位？
为了帮助信号或信号组的接收端来识别发送端是否在发送前更新了信号或信号组的数据，AUTOSAR COM模块整出了“更新位”（Update Bit），它表征的是发送端RTE在通过I-PDU传递给PDUR前，信号是否更新。
如果传输模式设置为“DIRECT”，那就没有更新位一说了。
通过配置发送端和接收端，每个信号或信号组都可以分配一个更新位，来表征其更新状态，配置参数为ComUpdateBitPosition，因此可以知道，信号和对应的更新位在相同I-PDU内，即在CAN总线上，位于相同以帧CAN报文中。当然，信号或信号组也可以不配置更新位。
当RTE调用Com_SendSignal函数来更新信号值（或者调用Com_SendSignalGroup更新信号组）时，AUTOSAR COM模块将会将UB置为1。
当PduR_ComTransmit函数将I-PDU中的函数发送出去并反馈E_OK后，AUTOSAR COM模块将会把信号或信号组对应的UB清为0，此时需要将参数数ComTxIPduClearUpdateBit配置为传输（Transmit）。
当PduR_ComTransmit函数将I-PDU中的函数发送出去，反馈E_OK并成功确认后，AUTOSAR COM模块将会把信号或信号组对应的UB清为0，此时，参数ComTxIPduClearUpdateBit 需要配置为确认（Confirmation）。
当 Com_TriggerTransmit 函数成功请求I-PDU的信号后，AUTOSAR COM模块将会把信号或信号组对应的UB清为0，此时，参数ComTxIPduClearUpdateBit需要配置为触发传输（TriggerTransmit）。
当然，在通信矩阵的说明文档制作之时，就应该规定好信号或信号组合对应更新位的关系。比如，在制作dbc文件时，要标注报文消息中信号A和对应的更新位A _UB，以及信号组G和对应信号组的更新位G_UB。同时，信号和对应更新位一定要在相同消息中传递。如果dbc将一个信号的更新位单独拿出来，做成了两个信号，那么配置工具将无法进行更新位的配置。也正因为更新位是定义在相同一帧消息报文中，所以通信矩阵确认定义好，根据通信矩阵的定义配置即可。
试想，车内各控制器节点通过CAN传递数据。假设PEPS节点通过一条报文消息将起动请求信号A传递给TCU节点，但并不想把点火开关信号B传递给TCU，从网络布置最大化来看，刚好A和B处在同一帧报文中，TCU在接收到报文消息后判断是否响应B。
有了UB以后，就可以轻松处理该场景了。TCU接收到B后先判断B_UB是否置1，PEPS显然不希望将B_UB置1，这时，PEPS就可以一直保持B_UB一直为0，TCU就无法更新接收到的B信号了。CAN矩阵不需要制作很多版本，即满足了归一化的需求，也实现了不同项目的个性化配置。
有问题请在菜单栏添加作者微信咨询。
作者简介：
Demu，传统汽车电控向智能驾驶转变的汽车人。从事发动机控制器系统工程师和软件工程师多年，有丰富的ECU系统和软件设计经验。欢迎大家一起留言交流，共同进步。
点击“在看”是莫大的鼓励！
原文始发于微信公众号（汽车控制与人工智能）：如何理解CAN通信中的UB？
