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

An Internet Protocol address is a numerical label such as 192.0.2.1 that is connected to a computer network that uses the Internet Protocol for communication. An IP address serves two main functions: network interface identification and location addressing.

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 fourth version of the Internet Protocol (IP). 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 Internet Protocol (IP) is the network layer communications protocol in the Internet protocol suite for relaying datagrams across network boundaries. Its routing function enables internetworking, and essentially establishes the Internet.

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. The SCSI standards define commands, protocols, electrical, optical and logical interfaces. The SCSI standard defines command sets for specific peripheral device types; the presence of "unknown" as one of these types means that in theory it can be used as an interface to almost any device, but the standard is highly pragmatic and addressed toward commercial requirements. The initial Parallel SCSI was most commonly used for hard disk drives and tape drives, but it can connect a wide range of other devices, including scanners and CD drives, although not all controllers can handle all devices.

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> Protocol facilitating connection of one IP address space to another

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 (standard)</span> Standard in building automation

KNX is an open standard for commercial and domestic building automation. KNX devices can manage lighting, blinds and shutters, HVAC, security systems, energy management, audio video, white goods, displays, remote control, etc. KNX evolved from three earlier standards; the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus. It can use twisted pair, powerline, RF, or IP links. On this network, the devices form distributed applications and tight interaction is possible. This is implemented via interworking models with standardised datapoint types and objects, modelling logical device channels.

A Controller Area Network is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other's applications without a host computer. It is a message-based protocol, designed originally for multiplex electrical wiring within automobiles to save on copper, but it can also be used in many other contexts. For each device, the data in a frame is transmitted serially but in such a way that if more than one device transmits at the same time, the highest priority device can continue while the others back off. Frames are received by all devices, including by the transmitting device.

<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 computer motherboards for communication with the power source for ON/OFF instructions.

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 serial network protocol used for communication between components in vehicles. It is a single wire, serial network protocol that supports communications up to 19.2 Kbit/s at a bus length of 40 meters. The need for a cheap serial network arose as the technologies and the facilities implemented in the car grew, while the CAN bus was too expensive to implement for every component in the car. European car manufacturers started using different serial communication technologies, which led to compatibility problems.

<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. OBD systems give the vehicle owner or repair technician access to the status of the various vehicle sub-systems. The amount of diagnostic information available via OBD has varied widely since its introduction in the early 1980s versions of on-board vehicle computers. Early versions of OBD would simply illuminate a malfunction indicator light (MIL) or "idiot light" if a problem was detected, but would not provide any information as to the nature of the problem. Modern OBD implementations use a standardized digital communications port to provide real-time data in addition to a standardized series of diagnostic trouble codes, or DTCs, which allow a person to rapidly identify and remedy malfunctions within the vehicle.

6LoWPAN was a working group of the Internet Engineering Task Force (IETF). It was created with the intention of applying the Internet Protocol (IP) even to the smallest devices, enabling low-power devices with limited processing capabilities to participate in the Internet of Things.

NMEA 2000, abbreviated to NMEA2k or N2K and standardised 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 and conforms to 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.

RTP-MIDI is a protocol to transport MIDI messages within 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.