RV-C

Last updated

RV-C is a communications protocol based on the Controller Area Network bus. The protocol is used in recreation vehicles to allow house and chassis components to communicate. RV-C is used for control, coordination, and diagnostics, in a multi-vendor environment.

Contents

Development History

RV-C was initially developed by the Recreational Vehicle Industry Association. The first formal specification was approved in 2005, and the first RV-C products were marketed at that time. The RVIA has continued to refine and expand the protocol, and in 2008 applied to ISO with the intention of opening the RV-C protocol to the world community.

In 2006 the first RV-C-equipped RVs were sold in America. The leading adopters were Country Coach, Foretravel, Newell Coach, and Western RV. RV-C-compliant components for these RVs were manufactured by Valid Manufacturing Ltd., Automated Engineering Corp, SilverLeaf Electronics, and HWH Corporation.

In 2007, the RVIA hosted a Network Fest at their main industry show. The Fest was an educational event featuring over two dozen RV-C compliant products from 14 exhibitors.

Protocol Overview

RV-C is based on Controller Area Network, and operates at a bus speed of 250 kbit/s. Data is contained in packets consisting of a header and eight data bytes. The header contains an 8-bit Source Address and a 17-bit Parameter Group Number, as well as a few additional bits. The total bus capacity is approximately 2500 data packets per second, although in practice bus loads are much lower.

RV-C is peer-to-peer. Each CAN transceiver on the network requires a unique source address, which can be assigned either dynamically or statically. Data packets are prioritized based on their contents, not the device.

The Application Layer details the Parameter Group Numbers, which uniquely identifies how the contents of the data packet are to be interpreted. The primary work of the RV-C committee is the creation of new Parameter Groups as new components are introduced in the RV marketplace.

To be considered RV-C-compliant, a device must support certain PGNs. These are

A key concept in RV-C is the instance. In an RV, multiple "instances" of a device are common. RV-C handles this using a unique method in which an instance number is assigned to each physical unit of a certain type.

An idea that underlies much of RV-C's design is that "every data packet stands alone". That is, with very few exceptions, all the information necessary to interpret a data packet is contained within that packet. This greatly reduces the memory and speed required for a microprocessor to implement the protocol. In general, the committee has been intent on keeping the cost of implementation to a minimum.

Relationship to SAE J1939

RV-C draws heavily from the SAE J1939 protocol. The primary differences between J1939 and RV-C are:

The RVIA web site for RV-C

Related Research Articles

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address. For example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.

<span class="mw-page-title-main">IPv4</span> Fourth version of the Internet Protocol

Internet Protocol version 4 (IPv4) is the first version of the Internet Protocol (IP) as a standalone specification. It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 was the first version deployed for production on SATNET in 1982 and on the ARPANET in January 1983. It is still used to route most Internet traffic today, even with the ongoing deployment of Internet Protocol version 6 (IPv6), its successor.

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

<span class="mw-page-title-main">SCSI</span> Set of computer and peripheral connection standards

Small Computer System Interface is a set of standards for physically connecting and transferring data between computers and peripheral devices, best known for its use with storage devices such as hard disk drives. SCSI was introduced in the 1980s and has seen widespread use on servers and high-end workstations, with new SCSI standards being published as recently as SAS-4 in 2017.

The Address Resolution Protocol (ARP) is a communication protocol used for discovering the link layer address, such as a MAC address, associated with a given internet layer address, typically an IPv4 address. This mapping is a critical function in the Internet protocol suite. ARP was defined in 1982 by RFC 826, which is Internet Standard STD 37.

<span class="mw-page-title-main">Network address translation</span> Technique for making connections between IP address spaces

Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. The technique was originally used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced, but could not route the network's address space. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.

<span class="mw-page-title-main">KNX</span> Standard in building automation

KNX is an open standard for commercial and residential building automation. KNX devices can manage lighting, blinds and shutters, HVAC, security systems, energy management, audio video, domestic appliances, displays, remote control, etc. KNX evolved from three earlier standards; the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus.

<span class="mw-page-title-main">CAN bus</span> Standard for serial communication between devices without host computer

A controller area network (CAN) is a vehicle bus standard designed to enable efficient communication primarily between electronic control units (ECUs). Originally developed to reduce the complexity and cost of electrical wiring in automobiles through multiplexing, the CAN bus protocol has since been adopted in various other contexts. This broadcast-based, message-oriented protocol ensures data integrity and prioritization through a process called arbitration, allowing the highest priority device to continue transmitting if multiple devices attempt to send data simultaneously, while others back off. Its reliability is enhanced by differential signaling, which mitigates electrical noise. Common versions of the CAN protocol include CAN 2.0, CAN FD, and CAN XL which vary in their data rate capabilities and maximum data payload sizes.

<span class="mw-page-title-main">DMX512</span> Digital communication network standard for controlling stage lighting and effects

DMX512 is a standard for digital communication networks that are commonly used to control lighting and effects. It was originally intended as a standardized method for controlling stage lighting dimmers, which, prior to DMX512, had employed various incompatible proprietary protocols. It quickly became the primary method for linking controllers to dimmers and special effects devices such as fog machines and intelligent lights.

The System Management Bus is a single-ended simple two-wire bus for the purpose of lightweight communication. Most commonly it is found in chipsets of computer motherboards for communication with the power source for ON/OFF instructions. The exact functionality and hardware interfaces vary with vendors.

A vehicle bus is a specialized internal communications network that interconnects components inside a vehicle. In electronics, a bus is simply a device that connects multiple electrical or electronic devices together. Special requirements for vehicle control such as assurance of message delivery, of non-conflicting messages, of minimum time of delivery, of low cost, and of EMF noise resilience, as well as redundant routing and other characteristics mandate the use of less common networking protocols. Protocols include Controller Area Network (CAN), Local Interconnect Network (LIN) and others. Conventional computer networking technologies are rarely used, except in aircraft, where implementations of the ARINC 664 such as the Avionics Full-Duplex Switched Ethernet are used. Aircraft that use Avionics Full-Duplex Switched Ethernet (AFDX) include the Boeing 787, the Airbus A400M and the Airbus A380. Trains commonly use Ethernet Consist Network (ECN). All cars sold in the United States since 1996 are required to have an On-Board Diagnostics connector, for access to the car's electronic controllers.

Society of Automotive Engineers standard SAE J1939 is the vehicle bus recommended practice used for communication and diagnostics among vehicle components. Originating in the car and heavy-duty truck industry in the United States, it is now widely used in other parts of the world.

LIN is a network protocol used for communication between components in modern vehicles. It is a low-cost single-wire serial protocol that supports communications up to 19.2 Kbit/s with a maximum bus length of 40 metres (131.2 ft).

<span class="mw-page-title-main">On-board diagnostics</span> Automotive engineering terminology

On-board diagnostics (OBD) is a term referring to a vehicle's self-diagnostic and reporting capability. In the United States, this capability is a requirement to comply with federal emissions standards to detect failures that may increase the vehicle tailpipe emissions to more than 150% of the standard to which it was originally certified.

OBD-II PIDs are codes used to request data from a vehicle, used as a diagnostic tool.

NMEA 2000, abbreviated to NMEA2k or N2K and standardized as IEC 61162-3, is a plug-and-play communications standard used for connecting marine sensors and display units within ships and boats. Communication runs at 250 kilobits-per-second and allows any sensor to talk to any display unit or other device compatible with NMEA 2000 protocols.

Sercos III is the third generation of the Sercos interface, a standardized open digital interface for the communication between industrial controls, motion devices, input/output devices (I/O), and Ethernet nodes, such as PCs. Sercos III applies the hard real-time features of the Sercos interface to Ethernet. It is based upon the Ethernet standard. Work began on Sercos III in 2003, with vendors releasing first products supporting it in 2005.

In mobile-telephone technology, the UniPro protocol stack follows the architecture of the classical OSI Reference Model. In UniPro, the OSI Physical Layer is split into two sublayers: Layer 1 and Layer 1.5 which abstracts from differences between alternative Layer 1 technologies. The actual physical layer is a separate specification as the various PHY options are reused in other MIPI Alliance specifications.

ISO 15765-2, or ISO-TP (Transport Layer), is an international standard for sending data packets over a CAN-Bus. The protocol allows for the transport of messages that exceed the eight byte maximum payload of CAN frames. ISO-TP segments longer messages into multiple frames, adding metadata (CAN-TP Header) that allows the interpretation of individual frames and reassembly into a complete message packet by the recipient. It can carry up to 232-1 (4294967295) bytes of payload per message packet starting from the 2016 version. Prior version were limited to a maximum payload size of 4095 bytes.

RTP-MIDI is a protocol to transport MIDI messages within Real-time Transport Protocol (RTP) packets over Ethernet and WiFi networks. It is completely open and free, and is compatible both with LAN and WAN application fields. Compared to MIDI 1.0, RTP-MIDI includes new features like session management, device synchronization and detection of lost packets, with automatic regeneration of lost data. RTP-MIDI is compatible with real-time applications, and supports sample-accurate synchronization for each MIDI message.