资讯动态

RV-C协议学习笔记(1)----序言CAN ID 解析

发布时间:2026/10/24 4:12:08 来源:尧图企业网站定制
文章目录1.序言2.核心术语说明2.1 Node or RV-C Node or CAN Node —— 硬件实体2.2 SA (Source Address) —— 节点的唯一身份证2.3 Device Type (设备类型) —— 节点内部的软件分身2.4 DSA (Default Source Address) —— 诊断报警时的“临时工牌号”3 RV-C 报文**在总线上的原始 29-bit CAN ID 结构**以及**数据域**3.1 报文的底层身份29-bit CAN ID 的三大要素3.1.1 优先级 (Priority) —— 决定谁先发3.1.2 数据组编号 (DGN) —— 决定“内容是什么”3.1.3 源地址 (Source Address, SA) —— 决定“我是谁”3.2 报文的实际载荷数据域 (Data)总结1.序言最近在开发 RV-C 协议相关的产品网上能检索到的 RV-C 协议资料相对较少只能自己摸索。这里记录一些我对协议的理解既便于开发过程中随时回溯也方便与需要使用这个协议的朋友互相学习探讨。RV-C 全称‌RV Industry Association Communication‌房车行业协会通信是由‌北美房车工业协会RVIA‌制定的、基于‌CAN 2.0 总线‌的房车专用通信标准用于实现房车内部电子设备之间的标准化数据交换。‌‌‌协议简介的原文如下RV-C is a CAN-based communication network for recreation vehicles. This document details physical, administration, diagnostic, and application requirements to allow all RV-C network connected devices to interoperate and be maintained.RV-C 协议的核心目的主要在于解决以下两大问题‌互操作性‌解决不同制造商设备之间的兼容性问题使控制系统、电源系统、娱乐系统等能够协同工作。‌标准化‌为制造商提供统一的设计规范降低开发复杂度与成本同时提升用户的使用体验。 目前开发欧美房车相关的产品大多都使用该协议。协议第二章主要介绍物理层相关的内容也就是硬件相关的内容。我们这里主要做的是协议解析因此直接跳过第二章。那就从协议的第三章开始吧。2.核心术语说明2.1 Node or “RV-C Node” or “CAN Node” —— 硬件实体原文:A microprocessor that sends and receives data on an RV-C bus. More technically, a CAN 2.0B master node consisting of a transceiver, controller, and microprocessor/microcontroller to implement the RV-C protocol.原文大致意思是收发器、控制器和 MCU 组成的 CAN 2.0B 主节点。协议在这里把“Node”严格定义为物理上的硬件板子。它强调的是硬件的物理存在一个收发器、一个 CAN 控制器。说白了就是一个基本硬件实体的意思主要的界限就是含有一个CAN通讯能力的硬件实体,比如说一个逆变器,当然如果这个设备中除了逆变还包含一个充电器,但是它共用一个CAN收发设备虽然是包含了两个设备但也是一个Node or “RV-C Node” or “CAN Node”.这里有三个名称为了后续的方便统一使用RV-C Node描述该术语.2.2 SA (Source Address) —— 节点的唯一身份证原文:A unique identifier for each node on an RV-C network. Source addresses may be hard coded by a device, or claimed dynamically on startup per section 3.3 of this specification. A node maintains a single source address regardless of the number of functions or device types it supports.原文的大致意思是SA (Source Address)是网络上每个节点的唯一标识符。节点仅维护一个唯一的源地址single source address无论它支持多少功能。SA 硬件板子的 IP 地址。无论这个板子上插了多少个功能模块或者跑了多少个虚拟机它在总线上的物理身份Source Address只有一个。就像2.1中举的例子,一个逆变器如果除了逆变还包含一个充电器,但是它共用一个CAN收发也就是一个Node or “RV-C Node” or “CAN Node”,就只能申请一个SA.这个SA名称后续再CANID组成中有使用,所以比较关键.2.3 Device Type (设备类型) —— 节点内部的软件分身原文:A set of functions or capabilities possessed by a node e.g. “awning”, “inverter”, or “water heater”. Each device type has a set of RV-C messages associated with it as defined in section 6 of this specification; e.g. a node supporting the “awning” device type might broadcast/receive RV-C messages “AWNING_COMMAND” and/or “AWNING_STATUS”.A node may support multiple device types or multiple instances of a device type (e.g. “awning 1” and “awning 2”.)原文的主要意思是RV-C Node拥有的一组功能或能力如“遮阳棚”、“逆变器”。节点可以支持多种设备类型或同一设备类型的多个实例如awning 1和awning 2。这是为“多合一”硬件比如前面的说的一个逆变器如果除了逆变还包含一个充电器的实现提供基础。Device Type 软件逻辑上的虚拟设备。虽然物理上只有一个 SA但板子内部的 MCU 可以“精神分裂”在逻辑上扮演多个 Device Type比如扮演逆变器又扮演充电器。esmp;原文中提到了awning 1和awning 2这就是协议中Instance实例概念的雏形用于区分同一类型下的不同虚拟设备。但是协议中的术语中并没有**Instance实例的说明,后面成章节才有说明,做一个关于Instance实例也放再后面再说,并且后续了解的内容积累多了一并说说关于Instance实例**的各种示例.2.4 DSA (Default Source Address) —— 诊断报警时的“临时工牌号”原文An identifier associated with each device type as defined in Table 7.2. The DSA is included when a node broadcasts its diagnostic message (DM_RV); a node supporting multiple device types broadcasts the DM_RV for each of its device types with the correct DSA in each DM_RV message.原文提及DSA与每个 Device Type 关联的标识符,具体定义再表7.2中。在广播DM_RV诊断报文时必须携带。支持多种设备类型的节点需要为每个设备类型发送对应的 DM_RV(这里提及的DM_RV是RV-C协议的相当重要的数据包后续会专门解析说明)。DSA主要解决一个RV-C Node中包含多个Device Type情况下诊断混淆的问题。对于一个RV-C Node只能有一个SA**那么当 一个内RV-C Node有Device Type A和Device Type B同时报警时怎么区分是谁在报警**这就是DSA存在的意义。当发送DM_RV时协议报文中填上特定 Device Type 对应的 DSA这样就能分清一个RV-C Node内具体是Device Type A还是Device Type B报警了那又有一个新的问题对于一个RV-C Node只能有一个SA**那么当 一个内RV-C Node有Device Type A1和Device Type A2同时报警时那DSA岂不是也是一样的那又怎么区分是谁在报警**这里只要就涉及到了DM_RV中的的Bank Select整个协议中关于Bank的说明较少个人认为如果SA一样DSA也一样的情况下就需要使用BANK来区分Device Type了后续解析DM_RV时候在详细说明3 RV-C 报文在总线上的原始 29-bit CAN ID 结构以及数据域CAN 报文的原始表格如下DLL fieldsRV-C name (abbreviation)DescriptionNameBitBase ID28 to 26Priority111b – Lowest priority 000b – Highest priorityBase ID25ReservedAlways 0bBase ID24 to 18Data Group Number - HighIdentifies how the data packet should be parsed, possibly in combination with the DGN-LowExtended ID17 and 16Data Group Number - HighIdentifies how the data packet should be parsed, possibly in combination with the DGN-LowExtended ID15 to 8Data Group Number - LowEither determines the target node for the message, or with the DGN-High determines how the data packet should be parsed.Extended ID7 to 0Source address (SA)Shall be unique for each nodeData64 to 0DataDefined in detail in the RV-C application profile specification3.1 报文的底层身份29-bit CAN ID 的三大要素RV-C 是基于 CAN 2.0b 扩展帧协议设计的它的 29 位 IDBase IDExtended ID被严格划分为了三部分分别承担不同的职责3.1.1 优先级 (Priority) —— 决定谁先发位置Bit 28 ~ 263 bit作用这是总线的**“VIP通道”**。当多个设备同时在总线上发消息时数字越小的优先级越高000b最高111b最低。实际应用例如DM_RV诊断报警的默认优先级是6(110b)而常规状态帧的优先级可能是7。这意味着当逆变器报警时即使总线很堵报警信息也能挤到最前面先发出去防止被常规数据淹没。3.1.2 数据组编号 (DGN) —— 决定“内容是什么”位置Bit 24 ~ 817 bit由 DGN-High (24-18) 和 DGN-Low (15-8) 组合而成。作用这相当于标明报文的**“内容类型”**。实际应用协议的DGN所以内容定义都再表7.7中比如DGN1FFFF表中含义为DATE_TIME_STATUS,解析端看到它就知道这是DATE_TIME_STATUS数据。3.1.3 源地址 (Source Address, SA) —— 决定“我是谁”位置Bit 7 ~ 08 bit作用这是节点的**“身份证号”**。协议要求每个节点的 SA 必须是唯一的。总线仲裁的兜底机制协议中特意强调了“当优先级相同时SA 作为最后的仲裁决胜局tiebreaker。”这里关于SA 的仲裁也是RV-C的重要内容后续会详细说明3.2 报文的实际载荷数据域 (Data)位置Data共 64 到 0 位即标准 CAN 帧的 8 字节数据。作用传递真实的数据包具体数据含义协议有关于每一个DGN的数据说说明。总结OK,关于序言就先写怎么多下一个章节重点说一下instance(实例)这个其实非常关键但是协议中的说明的内容并不多。以上所有都是个人的学习笔记若有错误的地方欢迎大家指点。探索不能只是看结果过程也很重要。知识就是财富每次积累一点点终究会有质的飞跃。联系方式wlcdemmo.top,wlcwjy163.com,个人工作室,欢迎大家指教。幽灵

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑