The terminology of multiplexing can be confusing. The computer world is filled with protocols such as USB, Ethernet, and TCP/IP. RV-C differs from all of these in one crucial way: RV-C is complete. Not in the sense that everything about the protocol is written – in fact, it will never be complete in that sense, since new products will be introduced and added to the definition far into the future. It is complete in the sense that it defines every aspect of communication, from the type of wire used to the specific data items transmitted. This is not true of most computer protocols, which typically define just one or two “layers”, such as the physical wiring, message routing, or message contents. We'll outline the major layers here.
The wiring used in an RV-C network is a simple twisted pair, installed in a bus topology. A “trunk” is laid (we recommend Raychem 2019E0309 as a 20 gage cable that satisfies the impedance limits), and terminated at each end with a 120 ohm resistor placed across the pair. Nodes are connected to the trunk by “drops” of the same cable, teed into the trunk. Drops can be no longer than six feet, and can connect only a single node. No shielding is required. The two lines are designated “High” and “Low” (or sometimes “+” and “-” or “A” and “B”). All nodes are connected high to high, low to low.
RV-C does not designate a particular connector. The RV-C lines may be on a separate connector or part of the main connector for a product. Generally it should not be connected via a splice to a pigtail. Permanent splices make it very difficult to locate a problem in the wiring.
Data on the network moves at 250 kbps – about five times faster than a fast modem. All data is sent in packets consisting of a 21 bit header and up to eight bytes of data. If the network bandwidth is 100% utilized there may be up to about 3000 packets transmitted per second.
The header identifies the contents of the packet – that is, what kind of data is enclosed. It also identifies the sender, and in some cases the intended recipient. Finally, it includes the “priority” - higher priority packets get transmitted before lower priority packets.
The details of how the CAN protocol determines which node gets to transmit at each moment are handled by the CAN Controller in the node hardware. The details are unimportant here, except that it must be noted that it relies on every node having a unique address. This “Source Address” is a number up to 255, and assigning this address is a key part of the RV-C implementation.
Within the header is an 18-bit number called the Parameter Group Number, or PGN, which identifies the contents of the packet. The largest part of the RV-C definition is the list of all the packet types, and the PGNs that identify them. A typical product may support a dozen or more PGNs, all of which are defined by the protocol.
Certain PGNs are common to all products – and for some support is mandatory. There are PGNs for assigning Source Addresses, and for identifying the manufacturer and model of the component. There are PGNs for providing diagnostic information and general operating status. There are even PGNs for identifying which PGNs the product supports.
At a minimum, every product must properly use and respond to the messages related to Source Address assignment, component identification, diagnostics and operating status, and identifying the PGNs the node supports. All else is optional – although every product will also have PGNs that directly relate to its operation that they would be naturally expected to support.
It should be noted that since RV-C is built upon international protocols, it always uses metric units. Nodes that use English units in their internal programming or data presentation must convert whenever they send or receive data.
The RVIA committee is working to define PGNs for all products that are expected to be on the market in the near future, but the list will surely expand as new applications are devised. Thus the process of defining PGNs is an ongoing one, and through the RVIA and ANSI a procedure is being put in place to allow every component vendor the opportunity to submit new PGNs for inclusion in the protocol.
Sometimes it may be appropriate for a node to include features that are outside the RV-C PGN definitions. For example, there may be very product-specific configuration or factory testing features that would not be appropriate for general use. RV-C defines a way for components to communicate “proprietary” messages, just for this purpose. The content of these messages does not need to be documented in the RV-C specification, and can even be encrypted if there are trade secrets to be protected. However, proprietary messaging should be reserved for those few situations where the conventional PGNs are not appropriate.
Among the PGNs required for all RV-C nodes is the Diagnostic Message. This PGN includes a general status indicator (red/yellow/green light), and if there are any problems with the node, a list of codes identifying the errors. Each error is identified with a System Identifier (“SID”) and a Failure Mode.
The SID is taken from a list of components defined for that particular product. For example, the generator start relay is assigned a particular SID. The Failure Mode identifies the way that particular component failed - “mechanical failure”, for example. By using SIDs and Failure Modes, all errors are distilled to a set of numbers transmitted on the network.
A simple diagnostic tool needs only to ask each node for its diagnostic status, and translate the SIDs and Failure Modes into terms a user can understand. Of course, many nodes will have more sophisticated tests implemented in their software.