北美房车通讯协议RV-C：CAN2.0应用详解

5星 · 超过95%的资源需积分: 50 42 浏览量更新于2024-07-17 收藏 1.49MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

RV-C是北美房车行业中广泛应用的一种基于CAN2.0的通讯协议（Communications Protocol），它是由Recreation Vehicle Industry Association (RVIA) 研发并推广的。RVIA是一个位于美国弗吉尼亚州Reston的行业协会，致力于房车通信标准的制定。RV-C的主要目标是为了确保房车内部各种设备间的高效、稳定通信，如电气系统、娱乐设备和安全控制系统等。 RV-C的规范定义了物理层（Physical Layer）的细节。物理层规定了电缆的使用，推荐使用无屏蔽双绞线，其特性包括主干电缆的18到24 AWG（美国电线规格，AWG代表美国标准电线规格系列）以及分支电缆的16到24 AWG。电缆的阻抗要求在95到140欧姆之间，以保证信号的传输质量。最长的传播延迟限制在5纳秒每米，最小的扭绞密度至少为25个扭结每米，这有助于减少电磁干扰和提高信号完整性。对于电缆的标记，如果未标明，应按照表2.1.1b中的颜色编码规则进行区分：CAN_H线通常为白色，CAN_L线为蓝色，而SHIELD线可以是裸露或带有特定颜色（如黑色、红色或黄色、绿色）。网络的拓扑结构被设计为线性总线形式，分支长度有限，这有助于简化布线并保持信号一致性。此外，物理层还涉及到网络的终端处理和连接方法，确保了信号能够正确地从一个设备传递到另一个设备，同时考虑到电缆长度对信号衰减的影响。为了实现良好的信号完整性和防止信号反射，终端电阻和终端匹配器的设置至关重要。 RV-C作为房车通讯协议，对于提升房车内部电子系统的集成度和可靠性起着关键作用。它不仅规定了电缆材料和连接标准，还对信号传输的质量进行了严格控制，确保了房车使用者能够享受到流畅的通信体验。通过遵循RV-C标准，制造商可以确保他们的产品与其他兼容设备无缝协作，提高了整个房车生态系统的效率和用户满意度。

资源详情

资源推荐

regardless of type.

Table Error: Reference source not found - Failure mode identifier

Value Description

0 Datum value above normal range

1 Datum value below normal range

2 Datum value erratic or invalid

3 Short circuit to high voltage (or complete sensor input failure)

4 Short circuit to low voltage (or complete sensor input failure)

5 Open circuit, or output current below normal

6 Grounded circuit, or output current above normal

7 Mechanical device not responding

8 Datum value showing error of frequency, pulse width, or period

9 Datum not updating at proper rate

10 Datum value fluctuating at abnormal rate

11 Failure not identifiable

12 Bad intelligent RV-C node

13 Calibration required

14 "None of the above" (use sparingly!)

15 Datum valid but above normal operational range (least severe)

16 Datum valid but above normal operational range (moderately severe)

17 Datum valid but below normal operational range (least severe)

18 Datum valid but below normal operational range (moderately severe)

19 Received invalid network datum

20 to 30 reserved

31 Failure mode not available

3.2.5.9 Reporting multiple failures

A device is able to implement multiple functions, multiple instances of a single function, or a combination thereof. Such a device

may have multiple errors at the very same time; a separate DM_RV for each function or for each instance shall be sent by the

device.

A device with multiple instances of the same function may broadcast faults either by sending a separate DM_RV for each

instance, or combining all faults in a multiple packet message.

NOTE 1 A device combining all faults in a multiple packet message is unable to signal the status of each instance

independently, because only one operating status byte is sent for the entire message. This is appropriate where the instances

are integral sub-system of the device. This is not appropriate where the instances have their own operating status.

EXAMPLE The legs of a transfer switch are instances, which are integral sub-systems of a device. A AC load switching

device has instances, where each instance has its own status.

NOTE 2 A diagnostic device have to be careful in deciding when a fault is no longer active, because of the ambiguity

December 17, 2015 3.2.5.9 - Reporting multiple failures

inherent in the handle of multiple instance devices. A device that transmits a DM_RV with both faults (Yellow and Red) set to zero

and a particular DSA surely indicates that there are no faults for that function within the device. But there may be another device

with the same function. A second SPN -RV from the same device and function does not necessarily mean the first fault is no

longer active. Any diagnostic device that needs to track the appearance and disappearance of faults have to take advantage of

the 1000 ms update rate of the DM_RV. The device have to use a timer to track the last appearance of the fault and the last

appearance of a DM_RV from the source device.

3.2.5.10 Encoding multiple faults in a multiple packet message

A device with multiple faults from the same DSA may be signals the faults using a multiple packet message (see 8.7). In this

case the SPN, FMI and occurrence count shall be transmitted for each subsequent fault. The operating status and DSA shall be

sent once and shall apply to all encoded faults.

The use of a multiple packet message is optional. It is defined in Table 3.2.5.10. All attributes not listed shall be identical to the

active diagnostic message (see 3.2.5.1b).

Table 3.2.5.10 — Signal and parameter definition

Byte Bit Name Data type Unit Value definition

0 - Operating Status uint8 - see 3.2.5.2

1 - DSA uint8 - see 3.2.5.4

First fault

2 - SPN-MSB uint8 - see 3.2.5.5

3 - SPN-ISB uint8 - see 3.2.5.5

4 5 to 7 SPN-LSB uint3 - see 3.2.5.5

0 to 4 FMI uint5 - see Error: Reference source not found

5 0 to 6 Occurrence count uint7 - 7Fh if not available

7 reserved - - Always 1

6 - DSA extension uint8 - FFh — No DSA extension defined for product

Second Fault

7 - SPN-MSB uint8 - see 3.2.5.5

8 - SPN-ISB uint8 - see 3.2.5.5

9 5 to 7 SPN-LSB uint3 - see 3.2.5.5

0 to 4 FMI uint5 - see Error: Reference source not found

10 0 to 6 Occurrence count uint7 - 7Fh if not available

7 reserved - - always 1

11 - DSA extension uint8 - FFh — No DSA extension defined for product

Subsequent faults

n - SPN-MSB uint8 - see 3.2.5.5

n+1 - SPN-ISB uint8 - see 3.2.5.5

n+2 5 to 7 SPN-LSB uint3 - see 3.2.5.5

0 to 4 FMI uint5 - see Error: Reference source not found

n+3 0 to 6 Occurrence count uint7 - 7Fh if not available

7 reserved - - always 1

December 17, 2015 3.2.5.10 - Encoding multiple faults in a multiple packet message

n+4 - DSA extension uint8 - FFh — No DSA extension defined for product

3.2.6 Proprietary messages

RV-C supports proprietary messages. The proprietary message is defined in Table 3.2.6.

Table 3.2.6: Proprietary message

Attribute Value definition

DGN EF00h

DGN-High EFh

DGN-Low Destination address, global messages (FFh) are not allowed

Priority 6, RV-C node may increase priority if appropriate.

Broadcast rate As needed

Data 0 to 7 Manufacturer-specific

There are two main applications for this DGN: for advanced configuration (usually via a service tool), and for adding features to

the protocol without publishing. Both should be handled with care. It is particularly important that the RV-C nodes involved

properly identify each other and use the destination address properly to prevent other RV-C nodes from trying to parse their

messages. (Consider that your message to calibrate a sensor may also be another manufacturer's message to run a slide room

in).

NOTE 1 There is a complete lack of controls on this DGN. There is nothing in the protocol to protect RV-C nodes from

incompatible messages. Therefore this DGN should be used very sparingly and carefully.

NOTE 2 A safe technique for using this method for advanced configuration is to begin any sequence with a

"password" from the configuration tool. The RV-C node should ignore all proprietary messages until it receives the desired

password. The password should "expire" eventually, so the when the configuration process ends the RV-C node stops parsing.

Although it is possible to use this message to implement functionality without publishing the method, this technique is to be used

only when the desired function is not supported in the published protocol.

3.2.7 Multi packet message

Data groups longer than eight bytes shall be sent using the multi-packet message protocol, which allows messages up to 1785

bytes. Each 'long message' is identified with a particular DGN, but the DGN definition is no longer limited to 8 data bytes. The

method uses an initial packet to set up the transfer, followed by up to 255 data packets.

This technique has several severe limitations. There are no provisions for flow control. The receiving nodes do not communicate

their readiness to receive data. The transmitter has no assurance that the data is being processed. There is no method for a

receiver to request a specific packet. If the entire DGN is not received correctly the receiving node shall request the entire DGN

again. A node shall only transmit one long message at a time, since data packets are not specifically identified in any way other

than the packet number. And long messages are relatively slow, because of the 50 ms gap between data packets. Therefore long

messages shall not be used for control and instrumentation purposes.

Long messages are implicitly required for the PRODUCT_ID, and are optionally used for the DM_RV DGN when multiple faults

are active. They are used rarely in the Application profile; generally for configuration purposes where substantial tables have to

be downloaded or uploaded.

3.2.7.1 Initial packet message

Table 3.2.7.1a defines the DG definition and Table 3.2.7.1b defines the signal and parameter definition for the initial packet

message.

Table 3.2.7.1a - DG definition

December 17, 2015 3.2.7.1 - Initial packet message

0 - Packet number uint8 - 1 to 255

1to 7 - Data - - Encapsulated DGN data

3.2.8 Product identification message

The product identification message is a string of 8-bit single-byte coded graphic characters /ISO8859-1/ of arbitrary length. It is

(usually) transmitted using the long-message protocol given above. (It is possible to use short IDs that are sent in one message).

NOTE Product identification is different than the ADDRESS_CLAIM described below. ADDRESS_CLAIM requires the

identification information to be looked up in a table, which may not be available in the service tool or display node.

Table 3.2.8 defines the product identification message.

Table 3.2.8: Product identification message

Attribute Value definition

DGN 65259 (FEEBh)

DGN-High 254

DGN-Low 235

Priority 6

Broadcast rate On request

Data 8-bit single-byte coded graphic character text, with four

field delimited by "*"

Field 1: Make

Field 2: Model

Field 3: Serial number

Field 4: Unit number (for products where the RV-C node

is separate from the mechanical unit.)

NOTE All fields are optional, but the delimiting "*" is not. Examples:

ACME*QX-125*A4323443**. INTERMEGACORP*FLUXMASTER 2000***.

The minimal response would be ****.

3.3 Address claiming procedure

3.3.1 Introduction

The RV-C node that has no assigned SA address may use the node claiming procedure to get an unique SA address.

3.3.2 Source Address claiming

The RV-C node requesting dynamically an SA begins with an address request message. Every RV-C node shall be able to

respond to the address request message with an address claimed message. RV-C nodes that are "hard wired" to an SA shall

respond to the address request in order to prevent a dynamically addressed RV-C node from taking its address. A dynamically

addressed RV-C node will try addresses until it finds one unclaimed. Once it finds an unclaimed address, it sends the address

claimed message.

Table 3.3.2a defines the address request message.

Table 3.3.2a: Address request message

Attribute Value definition

December 17, 2015 3.3.2 - Source Address claiming

剩余230页未读，继续阅读

天添2114

粉丝: 2
资源: 8

北美房车通讯协议RV-C：CAN2.0应用详解

《北美房车协议》 中文版， RV-CAN 中文版

北美市场准入.pdf

firmware-master.zip 官方给出的 Ubuntu mate 16.04 镜像并不支持树莓派 3 代 B+ 文件

gong.sheng-.concise.complex.analysis.(world.scientific,.revised.ed..2007).djvu

katalon project中导入java-diff-utils，但build.gradle中没有

量子力学概论_《量子力学新讲》参考文献

润色：Previous studies have shown that the L1 norm is superior to the L2 norm in the processing of high-frequency detail features.

def size1(n): result = "" for i in range(n): result = "".rjust(2 * i + 1, "*") + "\n" return result

matlab中enframe函数源代码

Katalon Studio8.6.0的Library Management中导入java-diff-utils，要如何操作才能在脚本中被成功调用

写一个Katalon工具导入Java-diff-utils实现对两个文件夹下同名文件作对比并将对比结果输出到结果文件中的例子。从新建工程开始

用java写一个比对字符串差异，并返回差异内容的方法

sgtitle的源代码

matlab taylorwin(n,nbar,sll)函数 c/c++代码实现

matlab splash

利用java-diff-utils与katalon对接，实现自动化针对两个文件夹下的同名文件做比较

最新资源

《北美房车协议》中文版， RV-CAN 中文版